AI時代の開発：Contextをコードとして管理する「Context as Code」の実践的アプローチ

• AIエージェントの出力品質を左右する「コンテキスト」を、コードと同様にCI/CDやテストの対象として管理する手法が提唱された。
• CLAUDE.mdやMCPなどの標準化が進む中、コンテキストの生成・評価・配布・観測というライフサイクル管理が重要となる。
• エンジニアは単なるプロンプトエンジニアリングを超え、AIの挙動を制御する「コンテキストのキュレーター」としての役割が求められる。

かつて2009年にDevOpsという概念が「OpsをDevのように扱う」というパラダイムシフトをもたらしたように、今、我々は「ContextをCodeのように扱う」という新たな転換点に立たされている。Patrick Debois氏がInfoQで語った内容は、単なるAIツールの紹介ではない。それは、AIエージェントが自律的にコードを生成する現代において、我々エンジニアが「何を管理すべきか」という根本的な問いに対する回答である。

多くのエンジニアが陥っている罠は、AIへのプロンプトを「一過性の指示」として捉えてしまうことだ。しかし、複雑なプロダクト開発において、オンボーディングのドキュメントやエッジケースの処理をすべて自然言語で記述し、それをエージェントに渡す行為は、もはや「コードを書くこと」と何ら変わらない。Debois氏が指摘するように、膨大なコードを数行の自然言語に圧縮できるのであれば、その自然言語こそがプロダクトの核心的な資産となる。これを「Context as Code」と呼ぶならば、我々は従来のSDLC（Software Development Life Cycle）を「CDLC（Context Development Life Cycle）」へと拡張しなければならない。

具体的には、コンテキストを単なるプロンプトの塊として放置するのではなく、バージョン管理し、テストし、CI/CDパイプラインに乗せる必要がある。例えば、CLAUDE.mdのような標準化されたファイル形式は、異なるエージェント間でのコンテキスト共有を可能にする重要な一歩だ。また、MCP（Model Context Protocol）の普及により、Slackの議論履歴や社内ドキュメントといった「散逸したコンテキスト」をAIが直接参照できるようになった。これは、かつて我々がライブラリの依存関係を管理していたように、AIが参照すべき「情報の依存関係」をエンジニアが設計・管理する時代が到来したことを意味している。

コードにユニットテストが不可欠であるのと同様に、コンテキストにも「テスト」が必要だ。しかし、多くの現場では「AIがそれっぽい回答を返せばOK」という甘い評価基準で止まっている。Debois氏が提示する評価手法は、よりエンジニアリング的で厳格なものだ。まず、SWE-benchのようなベンチマークを自社のコンテキストに適用し、特定のタスクに対してAIがどの程度の精度で解決できるかを定量化する必要がある。これは、Dockerコンテナ内でエージェントを走らせ、入力と出力を検証する自動化されたテストハーネスを構築することを意味する。

さらに興味深いのは、コンテキストに対する「リンター（Linter）」の概念だ。YAML形式のメタデータや、特定の構造を持つコンテキストファイルに対し、構文チェックや記述の冗長性を自動的に検証する仕組みを導入する。これは、AIを「LLM-as-a-judge」として活用し、コンテキストの記述スタイルがモデルにとって最適かどうかをフィードバックさせる手法にも繋がる。いわば、コンテキストのためのGrammarlyを自前で構築するようなものだ。

以下の表は、従来のコード開発と、これからのコンテキスト開発における管理手法の対比である。

このように、コンテキストを「テスト可能なアーティファクト」として扱うことで、非決定的なAIの出力を制御し、組織的な知識として蓄積することが可能になる。Vercelのような先進的な企業が、自社のライブラリに対するAIの最適化をテストハーネスとして提供している事実は、今後すべてのライブラリ開発者が「AIが使いやすいコンテキスト」を同梱すべき未来を暗示している。

結局のところ、我々エンジニアが直面しているのは「AIに何を語らせるか」という権限の委譲と、その結果に対する責任の所在だ。AIエージェントがコードを書く時代において、エンジニアの価値は「コードをタイピングする速度」から「AIが正しく動作するためのコンテキストを設計する能力」へと完全に移行した。もしあなたが、明日からAIエージェントを本格的に導入しようとしているなら、まずは「自社の開発ルールやベストプラクティスを、AIが解釈可能な形式でリポジトリにコミットする」ことから始めるべきだ。

しかし、ここで一つの痛烈な問いを投げかけたい。AIが生成するコードの品質が、我々が提供するコンテキストの品質に依存するならば、そのコンテキスト自体が「スパゲッティコード」化していることに、我々はいつ気づくのだろうか？ 複雑すぎる指示、矛盾するルール、古びたドキュメントが混在するコンテキストは、AIにとっての「技術的負債」そのものである。我々は、コードのデバッグだけでなく、AIの思考を誘導する「コンテキストのデバッグ」という新たなスキルセットを習得しなければならない。

実践的な処方箋として、まずは以下の3点を推奨する。第一に、プロジェクト内に`CLAUDE.md`や`AGENTS.md`を配置し、AIへの指示をコードベースの一部として管理すること。第二に、主要なタスクに対してAIが成功したか失敗したかを判定する簡単なテストスクリプトをCIに組み込むこと。第三に、MCPを活用して、社内のドキュメントやSlackの知見をAIが参照できる「組織的なコンテキストレイヤー」を構築すること。AIは魔法ではない。それは、我々が与えたコンテキストという鏡に映る、我々の思考の投影に過ぎない。あなたは、AIにどのような「鏡」を差し出す準備ができているだろうか？