CodeRabbitがClaude Marketplaceに登場！Learn more
Atsushi Nakatsugawa
June 24, 2026
1 min read
June 24, 2026
1 min read
共有
What is context engineering? A primer for AI-assisted teamsの意訳です。
コンテキストエンジニアリングとは、AIエージェントに適切な情報と構造を渡すための取り組みです。チームレベルでは共有された規約、コードベースの知識、過去のPR履歴、すべてのエージェントが引き継ぐべき意思決定を意味します。
多くの解説は、個人開発者が1つのプロンプトを調整する話で終わります。しかし本番コードをリリースするチームでは、取り組む範囲がさらに広がります。少ない、または古いコンテキストは、ハルシネーションによる変更、規約からの逸脱、見逃された不具合、止まってしまうレビュー待ち行列につながるためです。
プロンプトの文言はいまでも重要です。しかし、チーム規模のAI開発においては、エージェントがプロジェクトのコンテキストをどう取得し、保持し、適用するかに左右されるようになりました。ここを誤ると、エージェントはもっともらしいものの、レビュー担当者がすぐには見抜けない壊れ方をするコードを生成します。うまく設計できれば、その同じコンテキストが、レビュー担当者が結果を判断するために必要な材料になります。
プロンプトエンジニアリングは文言を最適化します。コンテキストエンジニアリングは、モデルが行動するときに利用できるものを決める検索、記憶、ツール、構造を加えます。
Shopify CEOのTobi Lütke氏は、2025年6月19日の投稿で、コンテキストエンジニアリングを「LLMがもっともらしくタスクを解けるように、タスクに必要なすべてのコンテキストを与える技術」と定義しました。
私は「プロンプト・エンジニアリング」よりも、「コンテキスト・エンジニアリング」という用語の方が気に入っています。 こちらの方が、その中核となるスキル（LLMがタスクを妥当に解決できるように、必要なコンテキストをすべて提供するという技）をより的確に表現しているからです。
Anthropicはプロンプトエンジニアリングを「LLMへの指示を書き、整理する方法」と定義しています。一方でコンテキストエンジニアリングについては、「LLM推論中に最適なトークン（情報）の集合を選び、維持するための戦略の集合であり、プロンプト以外からそこに入ってくる可能性のある情報もすべて含む」と説明しています。違いは、知識が作業に入る場所です。プロンプトエンジニアリングは、作成時に知識を埋め込みます。コンテキストエンジニアリングはベクトルデータベース、API、メモリストア、ツール出力から実行時に取得します。
重心は、文言から配線へ移りました。
エージェントによってコンテキスト管理は難しくなりました。すべてのステップが、整理すべきコンテキストをさらに生むからです。LLMアプリは、単発のチャットから複数ステップのエージェント型ワークフローへ移りました。そこではエージェントがツール出力、取得したファイル、中間推論、過去の応答を蓄積します。典型的なエージェントのタスクでは、多数のツール呼び出しが発生し、それぞれがコンテキストを追加して性能を下げてしまう可能性があります。
大きなコンテキストウィンドウになっても、この問題を解決できず、むしろ悪化させることもあります。トークンが増えるほど、モデルが必要とする根拠が埋もれやすくなります。特に、その情報がプロンプト内で移動する場合は顕著です。長い入力コンテキストに関する研究では、関連情報の位置が変わると性能が低下することが示されました。2025年の分析でも、無関係なトークンをマスクしていても、関連トークンが長いコンテキスト内にあると精度が下がることが分かっています。
ChromaDBのContext Rot（コンテキストの腐敗）に関する研究でも同じ傾向が見られました。入力が長くなるほど、出力の信頼性は下がります。それでも、何を入れるか、どう並べるか、残りをどう圧縮するかは選ばなければなりません。では、コーディングエージェントにとって適切なコンテキストとは何でしょうか。
エージェントのコンテキストは、プロンプトだけではありません。読めるファイルから、それらを取り巻く運用モデルまで広がっています。その組み合わせによって、エージェントが安全に動くのか、それとも単にもっともらしく動くのかが決まります。
LangChainは、コンテキストエンジニアリングを4つの操作、つまり write、select、compress、isolateを中心に整理しています。コーディング作業における素材は、コードベースのコンテキスト、Git履歴、依存関係、ツール定義、チーム標準、取得したドキュメントです。ラベル自体より、その下にある要点のほうが重要です。これらはどれも、レビュー担当者が結果を判断するためにも必要なものです。つまり、エージェントのコンテキストを薄くすると、レビュー担当者のコンテキストも同時に薄くなります。
Anthropicは、肥大化したツールセットをよくある失敗パターンとして挙げています。
「人間のエンジニアが、ある状況でどのツールを使うべきかを明確に言えないなら、AIエージェントにそれ以上の判断は期待できない」
ツール選択に関する研究では、すべてのツールを見せるのではなく、適切なツールを見せることでモデルの精度が上がることがわかりました。コンテキストが多ければ、自動的に良いコンテキストになるわけではありません。
チームでは、コンテキストは共有インフラです。すべてのエージェントとコントリビューターが引き継げる場所に置く必要があります。
よくあるパターンの1つは、バージョン管理されたルールファイルです。AGENTS.md、CLAUDE.md、.cursorrules、SKILL.mdはリポジトリ内に置かれ、永続的でプロジェクト固有のガイダンスを提供します。たとえばビルドコマンド、コーディング規約、テストルール、コードだけからはエージェントが推測できない制約です。グローバルファイルには個人のデフォルト、リポジトリレベルのファイルにはチーム標準、サブディレクトリのファイルには上書きルールを持たせます。
Martin Fowler氏は、チーム標準をコード化すること自体は新しいものではないと指摘しています。チームはすでに、lintルール、CIパイプライン、IaC（Infrastructure as Code）で行っているからです。AIによって変わるのは、コード化できる範囲です。Lintは構文を検出します。実行可能なチーム標準はペアプログラミング、メンタリング、共有経験を通じてしか伝わらなかったアーキテクチャ判断やレビューの厳密さまで表現できます。AGENTS.mdの効率に関する研究では、こうしたファイルが、エージェントが探索的なナビゲーションでプロジェクト構造を推測する必要性を減らすことが示されています。
チーム規模では、セッションの記憶喪失と古さという2つの失敗が支配的です。チェックインされたコンテキストファイルがなければ、すべてのセッションはゼロから始まります。そして、そのファイルがコードに追従しなくなると、エージェントはもう成り立たないルールに基づいて作業を続けます。チームはVitestへ移行したのに、ファイルにはまだjestを実行すると書かれている。サービス境界は変わったのに、ファイルは古い構成を説明している。ある解説記事は、これを端的に表現しています。エージェントは古いルールからコードを生成し続け、すべての開発者が原因に気づかないまま修正コストを払う、ということです。
その影響は、エンジニアリングリーダーがすでに追っている指標に表れます。チーム全体では、薄い、または古いコンテキストは、おおむね同じ4つの形で失敗します。
ハルシネーションによる依存関係。 USENIX 2025の研究では、コーディングモデルが無視できない頻度でパッケージを誤認し、オープンソースモデルは商用モデルより悪い結果になることが示されました。「slopsquatting」に関する論文は、その次に起こる攻撃を説明しています。攻撃者が、ハルシネートされた名前のパッケージを悪意あるパッケージとして登録するというものです。
規約からの逸脱。 エージェントは標準化しているライブラリや、これから再実装しようとしているものに対して既存の共通ユーティリティがあることなど、あなたのチームの規約を知りません。Martin Fowler氏は、ある開発者のプロンプトではAI生成コードがチーム規約から逸脱し、別の開発者のプロンプトでは規約に沿うという、分散したコストについて説明しています。470件のPRに基づくCodeRabbitのAI vs humanレポートは、この問題を数値化しています。AIと共同作成したPRでは、人間だけのPRに比べて可読性の問題が3.15倍多く発生していました。
見逃された不具合。 2億1100万行のコード変更を対象にしたGitClearの分析では、新しく追加されたコードが2週間以内に修正される割合が、2020年より2024年のほうが高いことがわかりました。投入されるコードは増え、その後すぐに手直しされるコードも増えています。
セキュリティ面では、状況はさらに鮮明です。Fortune 50のリポジトリにまたがるApiiroの分析について、Cloud Security Allianceは、AI支援を使う開発者がAIを使わない同僚の3〜4倍のペースでコードをコミットしていたと報告しています。6か月で、月次のセキュリティ検出はおよそ10倍に増えました。構文エラーは76%減り、ロジックバグは60%減りました。しかし権限昇格の経路は322%増え、アーキテクチャ設計上の欠陥は153%増えました。局所的な正しさは改善した一方で、システムレベルのリスクは悪化しました。
同じレポートは、レビュー上の非対称性も示しています。AIと共同作成したPRは全体で約1.7倍の問題を生み、ビジネスロジックの誤りを含むロジックと正確性の問題は、AIによるPRで75%多く発生していました。AIは局所的でパターンマッチしやすい作業では改善を続けていますが、広くコンテキストに依存する作業には、まだ深い読み込みが必要です。
エージェントがコードを書くのに役立つ同じ知識ベースが、そのコードが周辺システムに適合しているかをレビュー担当者が判断する助けにもなります。
生成の面では、モデルのコンテキストをファイル内だけからファイル横断の検索へ広げることで、完全一致精度を大きく改善できる場合があります。
検証の面では、コードレビュー理解度に関する研究で、PRのコンテキストにより詳しいレビュー担当者ほど、そのPRを理解するために必要なリソースが少ないことが示されています。そのコンテキストを持たないレビュー担当者は、表面的なフィードバックに寄りがちです。
初期のAIレビューシステムが失敗した理由も同じです。メソッド単位という制限の強い粒度で動作し、判断を信頼できるものにするファイル横断のコンテキストを欠いていたためです。
生成とレビューは同じ形で失敗します。コードを書く時点でエッジケースを見逃したエージェントは、レビュー時にもそれを見つけにくいでしょう。なぜなら、生成時に自分で作ったモデルに基づいて動いているからです。だからこそ、コードを書いたエージェントとは独立し、より深いコンテキストを使う検証レイヤーが必要になります。
コード作成が速くなると、レビューが制約になります。GitHubのOctoverse 2025によると、2025年にマージされたPRは5億1870万件で、前年比29%増でした。コード生成は人間の注意力を上回るペースで伸びていますが、レビューする人の数は29%増えたわけではありません。
DORAの2025年レポートは、この点を率直に述べています。「AIは増幅器である」と。レポートは、速度向上の効果が、テスト、セキュリティレビュー、デプロイにおける下流のボトルネックに吸収されることが多いと警告しています。チームがレビュー体験を改善しなければ、AI生成コードの人間レビューは優秀なレビュー担当者を圧迫する可能性があります。
痛みが大きいのは末尾です。AI vs humanレポートでは、AIによるPRと人間だけのPRのあいだに、90パーセンタイルで2.11倍の差があることがわかりました。問題の多い少数の外れ値PRが、中央値よりはるかに多くのレビュー時間を消費し、それが待ち行列を詰まらせます。
Taskrabbitはコーディングエージェントを採用する前にレビューを改善し、平均マージ時間を10日から7日へ、25%短縮しました。AIコーディングエージェントによってPR量が増えた後、freeeは6か月で32.8週間分のレビュー時間を節約しました。
自律開発の負荷が高い環境で、Abnormal AIは、エージェント出力が増える中でも、重大度の高いレビューコメントで65%以上の受け入れ率に到達しました。教訓は繰り返されます。生成の改善は、検証も同時にスケールして初めて意味を持つということです。
コンテキストが豊富なAIコードレビューは、検証側からボトルネックに対処します。差分だけのレビューは、差分の先を見られないため、表面的な指摘に偏ります。CodeRabbitはPR、IDE、CLIでレビューします。そのコンテキストエンジンはコードベース、リンクされたチケット、過去のPR、チームの意思決定をインデックス化します。フィードバックは、動いた行だけでなく、変更を取り巻くシステムを反映します。また、既存の.cursorrulesや.copilot-instructionsも読み取り、CodeRabbit Learningsはレビュー会話内のレビュー担当者からのフィードバックを学習内容に変換し、将来のレビューを改善します。
CodeRabbitは、人間が差分を開く前に一次レビューを提供します。ただし、リリースの責任は引き続き開発者にあります。
コンテキストエンジニアリングは、エージェント型ライフサイクル全体の計画、レビュー、信頼を支える土台です。本当に必要な作業は、どのコンテキストを含めるか、それをどこに置くか、セッションやエージェントをまたいでどう永続化するか、コードの変化に合わせてどう最新に保つかを決めることです。そのコンテキストが深く共有されていれば、エージェントはより良いコードを書き、人間とAIのレビュー担当者はそれを判断できます。コンテキストが薄い、または古ければ、広いシステムリスクは局所的なチェックをすり抜けます。
CodeRabbitにとって、コンテキストエンジンは検証のための運用レイヤーです。コードグラフ分析によってファイル横断のコンテキストを構築し、チーム標準をレビューに持ち込み、自動リンターも追加します。また、レビュー担当者のフィードバックを学習内容に変換し、次のレビューをより鋭くします。これらはすべて、ライフサイクルのレビュー側、つまり危険な欠陥が残りやすい場所に向けられています。
しかし、ツールは意思決定の下流にあります。チームを守るのは、コンテキストをインフラとして扱うことです。エージェントとレビュー担当者に何を見せるかを決め、それを最新に保つことです。そこを正しくできれば、他のすべてが速くなったときにレビューだけが破綻する、という状態を避けられます。
本番環境に届く前に、より多くの問題を見つけましょう。今すぐCodeRabbitの14日間の無料トライアルを始めてください。
