CodeRabbit VSCode 拡張機能を試してみる

はじめに

こんにちは。リテールハブ開発部の池です。

昨今、AI を活用したコードレビューの方法は日を追うごとに選択肢が増えているように思います。

• GitHub Copilot - GitHub 上の PR に対して レビューコメントを自動生成
• Claude Code - /reviewコマンドを使ったローカルレビューや、Claude Code Actions による GitHub 上の PR レビュー
• Cursor - .cursorrulesファイルでカスタムルールを定義してのローカルレビューや、Cursor BugBot による GitHub 上の PR レビュー

このように、各ツールがローカルでのレビューと PR レビューの両方に対応しており、様々なレビューの方法があります。

今回は、2025 年 5 月に無料でリリースされた CodeRabbit VSCode 拡張機能を試してみました。PR レビューで有名な CodeRabbit ですが、ローカル環境でリアルタイムにコードレビューできるようになったということで、使い方を含め紹介できればと思います。

なお、今回の検証はCursorを使って行いました。VSCode 拡張機能として提供されていますが、Cursor でも問題なく動作することを確認しています。

CodeRabbit とは

CodeRabbit は、AI を活用した自動コードレビューツールです。元々は GitHub、GitLab、Bitbucket などと連携し、PR に対して自動的にレビューコメントを付けることで知られています。 これまでは主に有料会員に対する PR ベースのレビューが中心でしたが、2025 年 5 月に VSCode 拡張機能がリリースされ、ローカル開発環境でもその恩恵を受けられるようになりました。

詳しくは公式ページをご参照ください。

CodeRabbit VSCode 拡張機能

CodeRabbit VSCode 拡張機能は、ローカルの IDE 内でコードレビューを受けられる拡張機能です。この機能によって、PR を作成する前に問題を発見・修正できるため、開発効率の向上が期待できます。

主な特徴として以下があげられます。詳しくは公式ブログをご参照ください。

1. コンテキストを理解した高品質なレビュー

   • 単純な文法チェックだけでなく、コードの文脈を理解して意味のあるレビューを提供
   • 関数の使い方、変数の命名、コードの構造など、様々な観点から改善提案

2. リアルタイムレビュー

   • 設定によってはコミット時に自動的にレビューが実行される
   • PR を作成する前に品質を向上させることができ、レビュアーの負担も軽減
   • 未コミットの変更に対してもレビューを実行可能

3. AI による修正提案

   • 問題点を指摘するだけでなく、具体的な修正案も提示
   • 「Fix with AI」ボタンをクリックすることで、Claude Code, Cline, Roo など AI エージェントと連携して自動修正も可能

4. 幅広い言語サポート

   • JavaScript、TypeScript、Python、Java、C#、Go、Ruby など、主要なプログラミング言語をサポート
   • 言語に応じた適切なレビューを提供

料金

CodeRabbit の料金体系は以下です。

※ 2025 年 7 月 8 日時点の情報なのでご注意ください。最新の料金情報は公式料金ページをご確認ください。各プランの詳細な利用制限については公式 FAQをご確認ください。

プラン比較

プラン	月額料金	VSCode 拡張機能レビュー回数	PR レビュー	主な機能
Free	無料	1 時間あたり 1 回	基本機能のみ	・PR 要約 ・無制限のリポジトリ ・14 日間の Pro 無料トライアル
Lite	$12/月（年間契約） $15/月（月次契約）	1 時間あたり 1 回	拡張機能	・無制限の PR レビュー ・カスタマイズ可能な学習機能 ・リアルタイム Web 検索 ・コードグラフ分析
Pro	$24/月（年間契約） $30/月（月次契約）	1 時間あたり 5 回	高度な機能	・Lite の全機能 ・Linter/SAST ツール対応 ・Jira/Linear 連携 ・エージェントチャット ・分析ダッシュボード
Enterprise	カスタム価格	要相談	全機能	・Pro の全機能 ・セルフホスティング対応 ・SLA サポート ・専任カスタマーサクセスマネージャー ・カスタムインテグレーション

VSCode 拡張機能だけを使う分には無料なので、まずは気軽に試すことができるのが大きな魅力だと思います。ただし、無料プランでは 1 時間に 1 回という制限があるため、頻繁にレビューを実行したい場合は Pro 以上のプランを検討が必要になります。

試してみる

導入手順

1. 拡張機能のインストール

VSCode（今回は Cursor）の拡張機能タブから「CodeRabbit」を検索してインストールします。

2. ログイン

インストール後、ログインが必要です。GitHub、GitLab、Azure DevOps、Bitbucket のいずれかのアカウントでログインできます。

3. 設定（オプション）

必要に応じて以下の設定を調整できます。

• Auto Review Mode: コミット時の自動レビューの有効/無効
• AI Integration: Claude Code, Cline, Roo など AI エージェントとの連携設定
• Review Timeout: レビューのタイムアウト時間（デフォルト 20 分）

レビューの実行方法

CodeRabbit には 2 つのレビュー開始方法があります。

1. 自動レビュー Git コミット後に自動的にダイアログが表示され、レビューを実行できます。

2. 手動レビュー VSCode アクティビティバーの CodeRabbit アイコンをクリックして、以下の 3 つのモードから選択してレビューを実行できます。

• Review uncommitted changes: 未コミットの変更のみをレビュー
• Review committed changes: コミット済みの変更のみをレビュー
• Review all changes: ベースブランチとの差分すべて（コミット済み＋未コミット）をレビュー

詳細な使い方

設定へのアクセス

CodeRabbit の設定は、サイドバーの右上にある歯車アイコンからアクセスできます。

Auto Review Mode 設定

コミット後の自動レビューの動作を制御。

• Disabled: 自動レビューを完全に無効化
• Prompt: コミット後に確認ダイアログを表示（デフォルト）
• Auto: 確認なしで自動的にレビューを開始

Agent Type（AI 統合）設定

「Fix with AI」機能で提案された修正を適用する方法を選択できます。

1. Native: VSCode の GitHub Copilot を使用（VSCode のみ対応）
2. Claude Code: ターミナルで Claude コマンドを実行（Claude Code のインストールが必要）
3. Codex CLI: Codex CLI ツールを使用
4. Cline: Cline 拡張機能を使用
5. Roo: Roo Code を使用
6. Kilo Code: Kilo Code 拡張機能を使用
7. Clipboard: 修正提案をクリップボードにコピー（手動で AI ツールに貼り付け）

Review Timeout 設定

レビューのタイムアウト時間を分単位で設定できます。

デフォルトは 20 分ですが、0 に設定するとタイムアウトを無効化できます。

ベースブランチの選択

レビュー時に比較対象となるブランチを手動で選択できます。デフォルトでは現在のブランチの親ブランチが自動選択されますが、任意のローカルブランチを選択可能です。

サイドバーに現在のブランチと比較対象のブランチが表示され、クリックすることで変更できます。

レビューの実行状況

レビュー実行中は、サイドバーでリアルタイムに進捗を確認できます。

「Setting up」→「Analyzing changes」→「Reviewing files」の順に処理が進み、レビュー対象のファイルがリスト表示されます。

過去のレビュー履歴

サイドバーの「Previous reviews」セクションで、過去に実行したレビューの結果を確認できます。これにより、修正の進捗を追跡しやすくなります。

過去のレビューには「cancelled」などのステータスも表示され、レビューの完了状況を把握できます。

レビュー機能を試してみました

実際に CodeRabbit がどのようなレビューをしてくれるのか、具体例を見てみましょう。

例 1: 既存コードスタイルへの統一提案と最新情報を踏まえた提案

ECS タスク定義の JSON ファイルをレビューした際の結果です。

CodeRabbit は以下の 2 つの指摘をしています。

1. クォートスタイルの統一

   • ダブルクォートとシングルクォートが混在していることを指摘
   • 既存のコンテナ定義がシングルクォートを使用しているため、それに合わせるべきという提案

2. Datadog Agent のバージョン更新提案

   • 現在のバージョン 7.67.0 から 7.67.1 へのアップデートを提案
   • CVE-2025-4565 と CVE-2025-49128 の脆弱性修正が含まれていることを明示（※ CodeRabbit は特定の脆弱性修正を理由として挙げていますが、実際の修正内容については公式リリースノートで確認することを推奨します。今回の指摘内容は issue で報告されている内容でした。）

特に注目すべきは、セキュリティ脆弱性情報を踏まえたバージョン更新の提案です。単純な構文チェックだけでなく、セキュリティの観点からもレビューを提供していることがわかります。(注意： AI レビューツールの指摘については、常に公式情報源での確認が重要です。)

また、バージョン 7.67.1 は 5 日前にリリースされたばかりの最新のバージョンだったのですが、そのような新しい情報を踏まえたレビューを行なっていることがわかります。

例 2: 複数ファイルにまたがる一貫性の確認

別のファイル（secrets.libsonnet）でも同様の指摘がありました。

プロジェクト全体の一貫性を保つため、同じ指摘であっても複数のファイルにまたがって同じ観点でレビューしてくれます。

例 3: レビューコメントを反映する機能

レビューコメントへの対応方法は 2 つあります。

1. Apply suggested change - 提案された変更を直接適用する場合
2. Fix with AI - AI ツールを使って対話的に修正する場合

「Apply suggested change」をクリックすると、CodeRabbit が提案した修正内容がそのまま適用されます。シンプルな修正の場合はこの方法が最も効率的です。一方、「Fix with AI」ボタンをクリックすると、選択した AI ツールで自動的に修正を適用できます。

Fix with AI による修正例

以下は、PHP コードでの冗長な例外処理に関する NITPICKS レビューの例です。

この NITPICKS レビューで「Fix with AI」ボタンをクリックすると、設定した AI ツール（この例では Claude Code）がターミナルで起動します。

Claude Code は問題を分析し、以下のような修正を提案します。

• 冗長なmatch式の削除
• デフォルト値が同じケースの簡略化
• コードの可読性向上

私の環境では、CodeRabbit 拡張機能の設定画面で Agent Type 設定を「Claude Code」にしているため、ボタンをクリックするとターミナルで Claude コマンドが実行され、提案された修正を対話的に確認しながら適用できます。

例 4: レビューの種類別表示

CodeRabbit は指摘の種類によって異なるラベルと色で表示します。

赤い「Potential Issue」ラベル - 潜在的な問題を示すレビューです。上記の例では、より適切なメソッドの使用に関する指摘（save()よりupdate()を使うべき）などが含まれています。

青い「Refactor Suggestion」ラベル - コードの改善提案を示すレビューです。この例では、PHP のメソッドに型ヒントを追加することで、型安全性と IDE 支援を向上させる提案がされています。

その他にも「Verification」という緑のラベルもありました。

所感

CodeRabbit VSCode 拡張機能を実際に使ってみて、以下の点が特に印象的でした。

良かった点

• レビューの的確さ - 単純な構文エラーだけでなく、コードの一貫性や保守性の観点からもレビューしてくれる
• 最新情報への対応 - 5 日前にリリースされたばかりの最新バージョンに関する指摘もあり、最新情報を踏まえたレビューをしてくれた
• レスポンスの速さ - コミット後すぐにレビューを実行できる
• 無料で使える - これだけの機能が無料で使えるのは驚き

実際のパフォーマンス

Laravel で 34 ファイル、合計 1,000〜2,000 行程度のコード変更をレビューした際の比較です。詳細は割愛しますが、内容は単純な CRUD の REST API 実装で、複雑なロジックを含まないような実装です。

※ この結果はあくまで Laravel で単純な CRUD の REST API 実装で試した結果であり、参考程度にご覧ください。言語、プロジェクトの規模や複雑さなど、様々な要因によって結果は異なると思います。

CodeRabbit VSCode 拡張機能

• レビュー時間：5〜10 分
• レビューコメント数：約 40 個
  • 同様の問題が複数箇所にある場合も、すべて個別にコメント
  • セキュリティ観点のレビューコメントもあり

GitHub Copilot（参考）

• レビュー時間：CodeRabbit より高速
• レビューコメント数：2 個
  • REST に準拠した適切な HTTP ステータスコードの使用に関するコメント
  • 複数ファイルにおける status の整合性に関するコメント

今回の例に関しては、レビューの速度については GitHub Copilot の方が早い一方で、CodeRabbit はより網羅的で細かなレビューを提供してくれました。

まとめ

CodeRabbit VSCode 拡張機能は無料プランの場合回数制限がありますが、機能を試すことは可能なので、まずは使ってみることをおすすめします。手元で実装した内容をその場ですぐにレビューできるのはとても便利で、レビュー効率を高めることができると思います。

CodeRabbit は今後も機能拡張が予定されているようなので、さらなる進化に期待したいと思います。

---

参考文献

公式ドキュメント

• CodeRabbit VSCode Extension - Visual Studio Marketplace
• CodeRabbit 公式サイト
• CodeRabbit Documentation
• Use the VSCode extension | CodeRabbit
• Configure the VSCode extension | CodeRabbit
• FAQs | CodeRabbit

AWS Summit Japan 2025 参加レポート

目次

はじめに

2025年6月25日(水)、26日(木)の2日間に渡り、幕張メッセにて AWS Summit Japan 2025 が開催され、 弊社の開発本部からも4名のエンジニアが参加しました。
7月11日までの期間限定でオンデマンド配信も行われているので、ぜひ公式サイトをチェックしてみてください。

aws.amazon.com

当日は非常に多くの参加者が訪れ、会場は大変盛り上がっていました。 ブースでは、様々な企業が AWS サービスの活用事例を紹介したりミニセッションを開催したりしていて、どこへ行こうか迷ってしまうほどで、 イベントの盛り上がりが強く感じられました。

本参加レポートでは、弊社のエンジニアが参加したセッションの中から、 印象に残ったものをご紹介したいと思います。

メッセージボード

ステージ風景

参加レポート

Amazon の事例から学ぶ生成 AI の実践的な活用と実装アプローチ

発表者: 田原 慎也さん(アマゾン ウェブ サービス ジャパン合同会社) レポート: 塚田

開発本部開発1部デリッシュキッチン開発部の塚田です。 私からは「Amazon の事例から学ぶ生成 AI の実践的な活用と実装アプローチ」の発表内容をご紹介します。

このセッションではAmazon社がどのようにAIを活用しそして改善していたっかの事例も含めて紹介されるものでした。

まず、2023年はPoCを企業としては取り組んでいたが今ではどのようにAI(生成AI)を自身のプロダクト、システムに応用するかを考えていると全体感を話されていました。 弊社でもデリッシュAI(Blog最後に資料等のリンクがあります)をはじめとしたAI活用を社内外問わず進めているので、そういった状況に置かれているのは身に染みて感じています。

初めにAmazonが実際にどのようにAIを活用しているのかAI creative studioを例に様々なデモをもとに紹介いただきました。

• 一つの画像から
  • 異なるコンセプトの画像を生成する
  • 画像の調整をする
  • 映像を作成する

これらのことが実施でき利用ユーザは本来集中するべき作業に時間を費やすことができるようになると感じました

次に、Amazonの商品ページを例にどのようにAIを活用しているかの紹介がありました。 Image Generatorというシステムの内容を構成図をもとに解説いただきました。 SageMakerAIを並列で活用する構成で生成させた成果物をSageMaker Ground Truthを活用して評価を行っているとのことでした。

ここで責任あるAIの話がありました。 昨年のAWS Summitでも責任あるAIという言葉は出ていましたが、その考え方を取り入れながら実際のプロダクトを構築していることが感じられました。

発表中2023年当時と現在の生成AIで出力された画像(映像)をサンプルとして表示されましたが、 これを実現するためには既存の処理に必要な仕組みを追加することで実現できていました。 ただし、より複雑になっていくとデータサイエンティストとエンジニアとのコミュニケーションが発生していくことになりここを改善するために オリジナルのカスタムSDKを作ったとのことでした。 これを活用することでデータサイエンティストは内部の処理はラップされやりたいことに集中できるようになったとのことでした。

こういった技術を使い利用者への影響が生産性を高くすることができていると発言がありました。

弊社内でも積極的にAIを社内外で活用していき生産性を高めていくことはもちろんですが、責任あるAIの意識も持ちながら開発していきたいと感じたセッションでした。

AI Agent時代のソフトウェア開発の型 〜Everything as Codeで叡智を伝える〜

発表者: ⾼野 賢司さん(アマゾン ウェブ サービス ジャパン合同会社) レポート: hond

開発本部開発1部デリシュキッチンAWGのhondです。 僕からは⾼野賢司さんによる「AI Agent時代のソフトウェア開発の型 〜Everything as Codeで叡智を伝える〜」の発表を紹介します。

AI Agent時代の現在までの変化を踏まえて、これからの時代の課題として「AIが意図した通りに動いてくれない」と「AI駆動開発のスキルや価値が周囲の⼈に伝わらない」の二点を挙げ、それらに対する解決策を提案されていました。

まず初めに「AIが意図した通りに動いてくれない」の解決策としてはタイトルにあるようにEverything as Codeが提案されていました。
Everything as CodeとはInfrastructure as Codeをはじめ、Observability as Code、Database as Codeなどのあらゆるものをコードとして管理することで変更追跡を可能にする手法です。詳細についてはAWS Well-Architectedに記述されています。 これによって再現性と一貫性が担保されるだけでなく、AIが理解できる形式になっていることで人間しか知らないコンテキストをなくす効果があります。

次に「AI駆動開発のスキルや価値が周囲の⼈に伝わらない」のパートでは、そもそもソフトウェアでビジネス価値を提供するとはどういうことかを振り返りつつ、AI駆動開発で期待すべき効果を振り返り、解決策が提案されていました。
AI駆動開発とは一朝一夕で身につくものではなく、時間をかけてマスターして初めて価値に気づくものだと言及されていて、それはまさに「型」であると紹介されていました。
「型」については「型」の再考からの引用で 「型」に含まれる叡智は、学習者にとって当初は未知であり、学習過程で内在化することで把握できるものである。 と定義されていて、組織としては「共通認識の醸成」と「場の提供」を行うことで習得する環境を整えられると紹介されていました。

Everything as Codeのアプローチに関しては弊社でもAtlassian MCPを使うなどしてなるべくAIとのコンテキスト差を減らすアプローチを試していましたが、Everything as Codeほど全てをコードで管理するところまでは至っていなかったのでまだまだコードやドキュメントとして落とし込んでいく必要があると感じました。
組織としてのアプローチに関しては「AIツールを活用した開発効率化勉強会」として社内でハンズオンを含む勉強会を開始したのですが、そのアプローチが間違っていないことを再確認できました。しかし、「共通認識の醸成」については加速できておらず、個人の情報収集能力に頼っている部分があるのでより一層力を入れていく必要があると感じました。

AI によってシステム障害が増える！？〜AI エージェント時代だからこそ必要な、インシデントとの向き合い方〜

発表者: 草間 一人さん（PagerDuty株式会社　プロダクトエバンジェリスト） レポート: 庄司( ktanonymous )

資料はこちらからご覧いただけます。

開発本部開発1部トモニテ開発部所属の庄司です。 私からは、PagerDuty さんの AI エージェント時代におけるインシデントとの向き合い方についての発表をご紹介します。

こちらのセッションでは、冒頭にエレガントパズル¹の『障害のほとんどはデプロイによって引き起こされる』という一節を引用し、デプロイに着目した時に、AI エージェント時代においてどのようなことが起こり、どのように向き合っていくべきなのかについてお話しいただきました。
AI の発展に伴い開発スピードが向上すると同時に、成果物をリリースする頻度も増加します。 すなわち、AI の発展に伴いデプロイ回数が増加していき、同時に、障害の発生頻度も増加すると言えます。
これを踏まえて、AI によって増加するインシデントに対して、AI の利用を止めるのではなく、AI を活用しながらインシデント対応していくべきだと言及されました。

ここでは、AI によるインシデント対応の考え方として、以下の3つの分類が紹介されました。

1. 全くの未知で新しいインシデント
2. 部分的には理解できているインシデント
3. 十分に理解できているインシデント

セッション中では、理解度が高いものであるほど AI 主導での対応が可能になるとして、 十分に理解できているような現象に対しては完全に AI で対応してしまって良いのではないかと言及されました。
一方で、未知の現象に対しては、まだまだ AI だけでの対応は難しく、人間が主導して AI を補助役として利用していくのが良いと言及されました。

AI によって生産性を向上させることは非常に重要なことですが、 それに伴ってインシデントの発生が増加することはあくまでも自然なことであると捉えられる側面もあり、 「インシデント」という確実な対応が求められる領域だからこそ、適切な AI の活用がしっかり考えていきたいと感じました。

生成AI活用で見えてきた3つの課題～精度・セキュリティ・推進体制～

発表者：村上 博哉さん（株式会社サーバーワークス　カスタマーサクセス部 CS４課 課長） レポート: 新谷

開発本部開発1部デリッシュキッチン開発部所属の新谷です。 私からは、サーバーワークスさんの「生成 AI 活用で見えてきた 3 つの課題 ～精度・セキュリティ・推進体制～」のセッションから、AI活用における3つの課題と対策についてご紹介します。

このセッションでは、多くの企業が生成AI導入で直面する3つの主要な課題として、「精度」「セキュリティ」「推進体制」が挙げられました。

1. 精度の課題
   ハルシネーションは完全には避けられない現象であり、生成AIに100%の精度を期待すべきではないという前提が示されました。対策として以下が紹介されました。

   • temperatureパラメータによる回答の一貫性と多様性の制御
   • 「階層的チャンキング」などの技術を活用したRAGの高度化

   階層的チャンキングでは、検索対象の情報だけでなく、その周辺情報もAIに渡すことで、より文脈に沿った回答生成が可能になります。

2. セキュリティの課題
   リスクを体系的に整理することから始めることの重要性が強調されました。具体的なアプローチとして以下が有効だと説明されました。

   • 「生成 AI セキュリティスコーピングマトリックス」による利用形態に応じた対策範囲の明確化
   • 「OWASP Top 10 for LLM Applications」によるLLM特有のリスクの洗い出しと脆弱性の特定

3. 推進体制の課題
   多くの企業が直面する人材・ノウハウ不足に対して、情報収集と実践経験の両輪で解決する必要があると言及されました。

   • 重要なのは「ゴール設定 → プロトタイピング → 評価」のサイクルを短期間で素早く回すこと
   • 小さな成功体験を積み重ねながら組織全体のノウハウを蓄積していく
   • 外部のPoC支援サービスを活用し、初期投資を抑えつつスタートを切る

弊社でも生成AIを活用したサービスを開発していますが、このセッションを通じて「技術検証だけでなく、KPIを設定した評価まで含めたサイクルを素早く回すことが成功の鍵」だと改めて実感しました。

弊社では生成AIを活用したサービスである「デリッシュAI」を開発しており、その詳細については以下の記事をご覧ください。

corp.every.tv

tech.every.tv

まとめ

AWS Summit Japan 2025 では、AI エージェント時代のソフトウェア開発やインシデント対応、生成 AI 活用の現場課題など、最新の技術トレンドや実践的な知見が数多く共有されました。 AI 時代ならではの開発手法やインシデント対応の考え方、生成 AI 導入における精度・セキュリティ・推進体制の課題とその対策など、今後の開発現場で重要となる視点を多く得ることができました。
また、各セッションを通じて「AI を活用しながらも人間の知見や組織的な学びをどう蓄積・共有していくか」が共通のテーマとして捉えられるような印象を感じました。

今後もこうしたイベントを通じて、最新技術の動向をキャッチアップしつつ、現場での実践に活かしていきたいと感じました。

最後に

エブリーでは、ともに働く仲間を募集しています。

テックブログを読んで少しでもエブリーに興味を持っていただけた方は、ぜひ一度カジュアル面談にお越しください！

corp.every.tv

最後までお読みいただき、ありがとうございました！

---

1. エレガントパズル　エンジニアのマネジメントという難問にあなたはどう立ち向かうのか↩

運用中のデータレイクアーキテクチャのストレージをS3 Tables へ移行するには

運用中のデータレイクアーキテクチャのストレージをS3 Tables へ移行するには

　こんにちは、開発本部 開発２部 RetailHUB NetSuperグループに所属するホーク🦅アイ👁️です。🎋七夕🎋が近いですが皆さまいかがお過ごしでしょうか。

背景

　最近我々のチームで管理しているAWSサービスにおいて本番環境のS3サービスが毎月右肩上がりにコスト上昇していることがわかりました。aws s3apiコマンドや、python SDKの get_cost_and_usage_with_resourcesAPIを駆使してコスト増の原因を調査した結果、非常に多くのGetObjectが呼ばれていることがわかりBIツールで日々分析データを出すクエリにてパーティションが効いてない状態であると推定し、クエリ見直しを行っている最中です。

　ところで、先月開催されたAWS Summit 2025にて「Amazon S3 によるデータレイク構築と最適化」という興味深いセッションがありました(参考資料)。Athenaで発行するクエリの最適化においてパーティションの課題解決策としてS3 Tablesを選択するという話が特に注目ポイントでした。

　現状運用中のアーキテクチャはS3にそのまま保存しているデータをAthena経由で検索しているのですが、そのストレージをS3 Tablesに移行すればパーティションを気にすることなくBIツールでの重いクエリ発行を抑えることができ、S3コストを結果的に減らせるのではないか、という期待からS3 Tablesに即座にかつ簡単に移行できるのか実際に調査してみることにしました。

• 通常S3運用に関する過去記事：tech.every.tv

前提条件

• 現在運用中の通常S3を使用したデータレイクアーキテクチャを崩さない移行を考える

要件

• Amazon S3 Tablesを使うこと
• Amazon Data Firehoseを使ってS3 TablesにINSERTできること
• Amazon Athenaを使ってS3 TablesにSELECTできること
• INSERTするデータは既存のS3データと同じであること

S3 Tablesを導入したトランザクショナルデータレイクアーキテクチャの構築

　データ集約管理において、通常のS3を使用したアーキテクチャをデータレイクアーキテクチャと呼びます。一方で、Apache IcebergサポートのS3 Tablesの特徴であるトランザクショナルを採用するアーキテクチャをトランザクショナルデータレイクアーキテクチャと呼びます(Amazon Redshiftのような従来のデータウェアハウスとの統合も兼ねる場合はさらにレイクハウスアーキテクチャという)。

　今回の調査では、Terraformを使わずAWSコンソールだけで構築を試みました。手順自体は概ね以下のリンク記事を参照したり、公式DOCにある手順を参照にするだけで問題なく設定はできました。

• aws.amazon.com
• docs.aws.amazon.com
• docs.aws.amazon.com

　あとは、この参照記事が2025年3月時点をベースにしていて5月14日にData Firehoseがresource linkを使わなくても直接S3 Tables用のGlue CatalogをDestinationに指定できるようになったのでその部分は省略できます。また、参照記事のCLIベースの手順部分も全てコンソール上で行えるようになっています。

　ただし、1点注意があって2025年7月現在、リソースリンクを使わない場合、新規作成はできますが、ConfigurationのEditをするとSaveするときになぜかdefaultのGlue Catalogを見てしまうバグがあり、設定変更を完遂できませんので設定変更をする可能性を残しておきたい場合は、依然としてリソースリンクを使った方法で作成してください。

 # Saveしようとしたら出てきたエラーメッセージ
 Your Firehose stream was not updated
Unable to update the Firehose stream XXXXX. Wait a few minutes and try again. If the problem persists, go to AWS Support Center .
API response
CatalogConfiguration cannot be updated.

編集前のS3 TablesのcatalogARN

編集画面上に表示されているcatalogARN

既存のデータを移行する方法を模索

問題発生

　既存のS3ファイルをGetしてファイルを読み込んでS3 TablesにINSERTできるように成形し直してData Firehoseに渡すスクリプトをpython SDK put_record_batchで実装して試してみたところ、CLIでテストしたときにBase64してからJSON形式にしてリクエストして成功したので同じリクエストデータを成形して実行するとエラーでコケてしまいました。

# 成功したときのCLIコマンド例
aws firehose put-record \
  --delivery-stream-name "$DELIVERY_STREAM_NAME" \
  --record "{\"Data\":\"$BASE64_DATA\"}"

# Destination error logs details
"errorCode":"Iceberg.InvalidPayload","errorMessage":"Delivery failed due to invalid input format. Make sure that the payload provided is in JSON Format."

解決策

　試行錯誤した結果、BASE64は不要のようでそのままPlainなJSON文字列を送ると上記のエラーが出なくなり、うまくINSERTされてAthenaでSELECTできました。

　余談ですが、当初はData Firehoseに渡す時点でテーブルスキーマに存在しないカラム名(JSONオブジェクトキー名)が一つでもあるとうまくINSERTされなかったので使わないKey-Valueセットをリクエストデータから省く前処理を追加していたのですが、2025年7月現在は未定義のKey-Valueセットが付随しているJSONデータでも問題なくINSERTできていました。

　これで後は移行タイミングで対象prefixの全オブジェクトに対してpythonスクリプトを実行すれば過去データの全移行も可能かと思います。

並行運用の場合

　次に、既存の運用も継続したまま並行してS3 Tablesも導入して徐々に移行していくというのを想定してみます。導入後の新ログだけS3 TablesにもINSERTすることでそれ以降のログは見れるようにするという場合、先ほどのpythonスクリプトをLambdaにして指定のS3バケットのprefixにPUTされたタイミングをトリガーにセットしてオブジェクトをGetするようにすればうまくいきました。

新規データを直接配信する方法

　まずは、単純にCloudWatch LogsのSubscription filtersのDestination ARNをS3 Tables用のData Firehose ARNに切り替えてパイプライン接続してみました。すると、当然のように以下のエラーでINSERT失敗してました。

# Destination error logs details
"errorCode":"Iceberg.InvalidPayload","errorMessage":"Delivery failed due to invalid input format. Make sure that the payload provided is in JSON Format."

　そこで、次にConfigurationのTransform recordsでLambdaで生ログを加工してデータを与える必要があるのでその設定を編集してSaveしようとしたら今度は以下のエラーが出てしまいました。

2 validation errors detected: Value at 'icebergDestinationUpdate.catalogConfiguration.catalogARN' failed to satisfy constraint: Member must have length greater than or equal to 1; Value at 'icebergDestinationUpdate.catalogConfiguration.catalogARN' failed to satisfy constraint: Member must satisfy regular expression pattern: arn:.*:glue:.*:\d{12}:catalog(?:(/[a-z0-9_-]+){1,2})?

　どうやら既存のData Firehoseをコンソール上から設定追加するのは現状だと不可能のようです。。

　次に新しくData Firehoseを作成し直してそこであらかじめ用意したLambda Functionをセットしておきました。すると、今後はLambdaにInvokeFunctionの許可を設定していないというエラーが出てしまいました。

"errorCode":"Lambda.InvokeAccessDenied","errorMessage":"Access was denied. Ensure that the access policy allows access to the Lambda function."

　そこでData Firehoseに割り当てているIAMポリシーを編集してLambdaのInvoke権限を追加しました(前述の公式DOC参照)。そうするとlambda実行自体は成功したのですが、今度はLambdaの処理がエラーになってしまいました。

"errorCode":"Lambda.FunctionError","errorMessage":"Check your function and make sure the output is in required format. In addition to that, make sure the processed records contain valid result status of Dropped, Ok, or ProcessingFailed"

　試行錯誤の結果、Data Firehoseにreturnで返す時のJSON文字列にする場合は、またdataキーの値がBase64エンコーディングされていないといけないということなのでそれを対応してようやくINSERTでき、AthenaでもSELECTできました！

まとめ

　コンソール上での環境構築は完成できたのでS3からS3 Tablesへの移行はできることがわかりました。今後は、移行後に実際どれだけBIツールでのクエリ発行によるコスト削減に貢献したかを検討予定です。また、Terraformを使って新規プロダクト開発環境での構築を目指す予定です。

　ちなみに、今回の調査で実際に半月ほどS3 Tablesにデータを流し続けていましたがBillsを見てみるとCompaction関連（コンパクションを行ったオブジェクトの数に対してのコストと圧縮処理を実行する（裏で密かにLambdaが走る？）コストの2種類）のコストも掛かっているのに気づきました。PUTのコストは通常のS3と同様でしたが、追加でCompaction関連のコストも嵩むのは注意が必要かもです。

Compacted Objects Cost

Processed Bytes Cost

最後に

エブリーでは、ともに働く仲間を募集しています。

テックブログを読んで少しでもエブリーに興味を持っていただけた方は、ぜひ一度カジュアル面談にお越しください！

corp.every.tv

Swift 6.2で導入される学習・導入しやすい並行処理(Approachable Concurrency)

Swift 6から本格的に導入された Strict Concurrency Checking は、アプリの安定性を飛躍的に向上させる一方、既存のコードの移行や、並行処理を初めて学ぶ開発者にとってはハードルが高いという課題がありました。

この課題に対応するため、Swift 6.2では「Approachable Concurrency」というビジョンが掲げられ、その中核機能として「Default Actor Isolation」が導入されました。

参考資料

この記事はWWDC 2025の以下のセッションを参考にしています。

• Swiftの並行処理の活用
• Code Along：Swiftの並行処理によるアプリの強化

Approachable Concurrencyとは？

これは、開発者がデータ競合のリスクを最小限に抑えつつ、必要な時にだけ段階的に並行処理を導入できるようにするための、Swiftの設計思想や機能群全体を指す言葉です。

このアプローチは、以下の3つのフェーズを想定しています。

1. シンプルなシングルスレッドのコードを書く: 並行処理について明示的に指定しない限り、全ての処理がメインスレッドで動作するコードになります。

2. データ競合のない非同期コードを書く: UIをブロックしてアプリが固まるなど問題があれば、async/awaitなどを使い、安全に非同期処理を導入します。

3. 並列処理でパフォーマンスを向上させる: アプリのパフォーマンスをさらに高める必要が出てきたら、TaskGroupやasync letなどを使い、複数の処理を並列で実行します。

並行性を段階的に導入することで、すべての開発者が最初から複雑な並行処理について深く理解する必要がないようにしています。

Default Actor Isolationとは？

これは「Approachable Concurrency」を実現するための新機能で、Xcode 26から作成する新規プロジェクトではデフォルトで有効になります。

• 概要: この設定が有効な場合、コードの大部分がデフォルトでメインアクタ @MainActor 上で実行されるように隔離されます。これにより、UIの更新などメインスレッドで行うべき処理が、意図せずバックグラウンドスレッドからアクセスされてクラッシュする、といった典型的なデータ競合を防ぎます。

• 既存プロジェクトでの設定: 既存のプロジェクトでは、Xcodeのビルド設定から Swift Compiler - Language にある Default Actor Isolation の項目を MainActor に変更することで、この機能を有効にできます。

• オプトアウト（分離の方法）: もちろん、重い処理をバックグラウンドで実行したいケースはあります。その場合は、関数や型に対して nonisolated キーワードや、Swift 6.2で導入された @concurrent 属性を明示的に指定することで、メインアクタから処理を切り離し、バックグラウンドで実行させることができます。

Swift 6.2での主な変更点

Default Actor Isolationをサポートするために、async関数の振る舞いがより直感的になるよう、いくつかの重要な変更が加えられました。

nonisolated async関数の振る舞いの変更

• Swift 6.1まで: nonisolated な非同期関数は、呼び出し元のアクタに関わらず、常にバックグラウンドのスレッドプールで実行されていました。

• Swift 6.2から: デフォルトで、呼び出し元の実行コンテキスト（アクター）を継承するようになります。つまり、 @MainActor から呼び出せば、その nonisolated async 関数も @MainActor 上で実行されます。これにより、意図しないスレッドの切り替えが減り、コードの振る舞いが予測しやすくなります。

新しい属性 @concurrent の導入

「nonisolated だけど、この処理は意図的にバックグラウンドで実行したい」という場合は、新しく導入された @concurrent 属性を関数に付与します。

これにより、Swift 6.1までの「常にバックグラウンドで実行する」という振る舞いを明示的に選択できます。

既存プロジェクトのSwift 6移行

Swift 5で開発中のプロジェクトをSwift 6に移行する場合、Swift 6.2をターゲットにすることで移行が簡単になる可能性があります。

移行プロジェクトの場合、 Approachable Concurrency = No、 Default Actor Isolation = nonisolated が選択されています。 これを、 Approachable Concurrency = Yes、 Default Actor Isolation = MainActor に変更することで、新規プロジェクトと同様に段階的に並行処理を導入できるようになります。

既存の考え方は、並行処理を基本としつつメインアクターへの隔離や、データ競合を避けるための制約や属性を付与することによって Strict Concurrency Checking に適合させるアプローチでした。

新しい考え方では、メインアクターでのシングルスレッド処理を基本としながら、必要な箇所にのみ段階的に並行処理を導入するアプローチに変わります。Approachable Concurrencyを採用することで、既存のコードの多くをそのまま活用しながら、段階的に並行処理を導入し、安全にパフォーマンスを向上させることができる可能性があります。

まとめ

Swift 6.2のDefault Actor IsolationとApproachable Concurrencyは、並行処理をより安全で、学習しやすくするための変更です。デフォルトでメインスレッドに処理を限定することで開発者をデータ競合から守りつつ、@concurrentのような新しい制御方法を提供することで、必要な箇所では意図的にパフォーマンスを最適化する手段を提供しています。

弊社で開発している「トモニテ」アプリは現在Swift 5で実装されており、できるだけ早くSwift 6に移行したいと考えています。しかし、Strict Concurrency Checking への対応が課題になっています。

そこで、Swift 6.2をターゲットとし、Approachable Concurrencyのアプローチを採用することで、従来よりも少ない変更量で安全に Strict Concurrency Checking に対応できる可能性があると考えています。今後、この手法を用いた移行の検証を行う予定です。

Android Studio Gemini の Agent Mode と rules について

ヘルシカ、デリッシュキッチンで Android アプリの開発を担当している岡田です。

時代の流れは早いもので、日々の開発業務で AI のサポートを受けることが当たり前になってきましたね。
今回は Android Studio Narwhal Feature Drop Canary 4 以降に Android Studio Gemini の Agent Mode がついに追加されましたので、 Gemini の rules 設定と合わせて見ていきたいと思います。
この記事が、皆さんの開発体験を向上させる一助となれば幸いです。

Agent Mode とは

まず、今回の目玉機能である「Agent Mode」から詳しく見ていきましょう。

これまでの Android Studio Gemini は、私たちが書いたコードの一部を選択して「この処理をリファクタリングして」と依頼したり、 チャットウィンドウで「〇〇の実装方法を教えて」と質問したりする、いわば「指示待ち」の優秀なアシスタントでした。
この機能は Chat Mode として残っています。

新しく登場した Agent Mode は、その名の通り「エージェント（代理人）」として、より能動的かつ自律的に動作します。
Google Developers 公式ドキュメントでは、以下の通りに紹介されています。

developer.android.com

Android Studio のエージェント モードの Gemini は、Gemini とのチャットだけではできない、複雑なマルチステージ開発タスクを処理するように設計されています。 大まかな目標を記述すると、エージェントが計画を作成して実行し、必要なツールを呼び出して複数のファイルに変更を加え、バグを反復的に修正します。 このエージェント支援ワークフローにより、複雑な課題に取り組んで開発プロセスを加速できます。

複数回のやり取りを通じて、Project 全体の構造やコードベース、依存関係、さらには設計思想まで深くコンテキストを理解し、ファイルやモジュールを横断して、より文脈に沿った的確なサポートを提供してくれるのです。
これまで複数の手順に分かれていた複雑なタスクを、一度の指示で実行できるようになります。

機能単位での実装

「アプリのホーム画面に、トピックのリストに移動する "フォロー" という新しいボタンを追加して」といった自然言語での指示から、必要な ViewModel、Composable 関数、Navigation の設定、さらには Unit Test の雛形まで、複数のファイルにまたがって生成・修正を提案してくれます。

高度なリファクタリング

「<composable name> コンポーザブルで、<modifier name> 修飾子のパディングを減らしてください」といったリファクタリング作業も、コード差分を明示しながら行なってくれます。

複雑なエラーの根本解決

「Project のビルドエラーを修正」などのプロンプトを使用してエージェントにビルドエラーの修正を依頼すると、推奨される修正が適用され、Project がビルドされてソリューションが検証され、問題が解決するまで反復処理されます。 根本原因を推測し、より堅牢な設計への改善案まで提示してくれます。

他にも Google Developers 公式ドキュメントにて、ユースケースについて記載されていますので、合わせてご覧いただけると幸いです。

developer.android.com

Agent Mode を使った実装の例

例として、テスト用の Project へカレンダー画面を作成してみましたので、その記録を以下に示します。

まずは Agent Mode を選択し、カレンダー画面を作成する旨を伝えます。
この時、@MainActivity と記載することで、明示的に MainActivity をコンテキストとして指定しています。

Gemini が CalendarScreen.kt というファイルに CalendarScreen という名の Composable 関数の作成案を提示してくれました。

ここで左右の矢印アイコン、Open in Diff View を選択すると、Diff View を見ることが可能です。

選択肢には Accept Change, Reject Change, Auto-Approve の 3 つがあります。

• Accept Change はこの提示された変更を許可します。今回の場合は Diff View で明示された変更が実行されます。
• Reject Change はこの提示された変更を拒否します。
• Auto-Approve はこの後に提示される変更を自動許可します。変更履歴は Gemini に常に表示されますが、ユーザの確認無しに一気に作業が実行されます。

今回は Auto-Approve を選択しました。その後、数回のエラー・警告解消のやり取りを通して出力されたものが以下になります。

デザインを見ると、確からしいものが出来ています。
正直人間がコードを見るとリファクタしたくなると思いますが、0-1 を行ってくれるのは大幅な作業短縮になる場合があります。
また今後、コーディング作業の大半を Gemini に任せるのであれば、もしかしたらリファクタリングは必要ないのかもしれません。
これはあくまで個人の感想ですが、AI にコーディングを任せる上で、「ある程度のブラックボックス化されたコードを黙認すること」に人間が慣れなければいけないのかもしれないなと思っています。

まだ全てを Agent に任せることは難しいですが、簡単なリファクタなどから仕事を任せてみてはいかがでしょうか。

rules 設定について

Agent Modeの能力を最大限に引き出すために不可欠なのが、rules（ルール） の設定です。

これまでは、Gemini に対して毎回「日本語で回答して」、「Compose で書いて」などといった前提条件を伝える必要があり手間でした。
しかしこのrulesを設定することで、前提条件をコンテキストとして Gemini に恒久的に教え込めます。

この機能は Android Studio の Settings > Tools > Gemini > Prompt Library から設定できます。

rules の Scope について

Gemini の rules は、IDE 全体に適用される設定と、特定の Project のみに適用される設定の 2 つのレベルで Scope を管理できます。

IDE 設定（グローバルルール）

どの Project を開いても適用される、開発者個人の好みや、組織全体で共有したい普遍的なルールを設定します。

Project 設定（Project 固有ルール）

その Project に特化したルールや制約、背景情報を定義します。チーム開発での利用が主目的です。

各設定の優先度

基本的には、Project 固有のルールが IDE のグローバルルールよりも優先されます。以下はその例です。

例) IDE 設定と Project 設定の優先度

IDE 設定の rules のみに「Always respond in 日本語 with utf-8 encoding.」と記述した場合、日本語で出力してくれます。

上記に加え、Project 設定の rules に「Always respond in English.」と記述した場合の出力は英語となります。

rulesに何を書くべきか

IDE 設定の rules

基本的には Project 設定の rules が優先されるため、本当に汎用的なものを記載するのが良いと思います。

• 「Always respond in 日本語 with utf-8 encoding.」

Project 設定の rules

Project 設定の rules には、Project の憲法となるような、具体的で明確な指示を記述することになると思います。

1. コーディング規約・スタイルガイド

• 「コメントは日本語で記述すること」
• 「Jetpack Compose の UI は、Google の公式マテリアル3デザインガイドラインに従うこと」
• 「マジックナンバー（説明のない数値リテラル）は使用せず、companion object 内で定数として定義すること」

2. 技術スタック（使用ライブラリやアーキテクチャ）の指定

• 「アーキテクチャは MVVM を採用する」
• 「状態管理はViewModelとStateFlowを使用する。LiveData は新規に採用しない」
• 「DI（Dependency Injection）には Hilt を使用する。Koin は使用しない」
• 「非同期処理は Kotlin Coroutines を使い、RxJava は使用しない」
• 「画像読み込みには Coil ライブラリを使用する」

3. Project の背景や目的

• 「このアプリは、IT 初心者向けの学習アプリです。コメントやドキュメントは、専門用語を避け、平易な言葉で記述してください」
• 「ターゲットユーザーは高齢者です。そのため、フォントサイズは大きめに設定し、クリック可能な領域も広く取るようなUIを心がけてください」

4. 禁止事項やアンチパターン

• 「Activity や Fragment 内で直接ネットワーク通信や DB アクセスを行わず、必ず Repository 層を介して行うこと」
• 「XML レイアウトでは findViewById は使用せず、常に ViewBinding を使用すること」
• 「Composable 関数内で重い処理を実行しないこと。必要であれば rememberCoroutineScope や副作用 API を適切に使用する」

これらのルールは、使用感や Project の成長に合わせてチームで議論し、変更していくことが重要だと思います。
例えば、「Gemini を使用している中で MVP アーキテクチャで回答が提示されたら、ルールに "アーキテクチャは MVVM を採用する" を追記する」といったフローで改善してくことになると思います。
弊社も rules は試行錯誤中ですが、記載内容を更新する度に求める回答に近づいている良い感覚があります。

まとめ

今回は Android Studioに搭載された Agent Mode と rules 設定について紹介させていただきました。
まずは最新の Android Studio Preview を導入し、簡単な rules からでも設定していただけると幸いです。
Gemini を「優秀なアシスタント」から「信頼できる開発パートナー」へと育て上げ、次世代の開発体験を楽しみましょう！