デボワ氏によれば、従来のソフトウェア開発では、開発者がコードそのものを記述していた。しかしAIコーディングエージェントの普及によって、開発者は「コードを書く人」から、「AIへ適切なコンテキストを与える人」へ変化しつつあるという。

　同氏は、「私は今や、コードをほとんど直接触らず、AIへ『こうしてほしい』と伝えている」と説明する。さらに、大量のコードや手順書、ノウハウを「スキル」としてまとめ、AIエージェントへ再利用可能な形で与える動きも進んでいると語る。

　デボワ氏は、こうした変化を踏まえ、「ソフトウェア開発ライフサイクル」（Software Development Life Cycle：SDLC）になぞらえた「コンテキスト開発ライフサイクル」（Context Development Life Cycle：CDLC）という考え方を提案している。

　CDLCは、DevOpsの思想をベースに、「コンテキストそのものをコード同様に運用・改善する」ための考え方だ。同氏は、AI時代には「プロンプトをコピー&ペーストして動けば終わり」という出たとこ勝負の運用ではなく、コンテキストそのものに対してエンジニアリングを適用する必要があると強調する。

　CDLCでは、企業は単にAIへプロンプトを入力するだけではなく、以下のような流れでコンテキストを継続的に改善する必要があるという。

コンテキストを生成する（Generate）

　AIへ与える“燃料”となるコンテキストを作成・集約するフェーズだ。従来のように、ユーザーが単発のプロンプトを都度入力するのではなく、「agent.md」や「Claude.md」「skill.md」といった共通ルールや制約条件を記述したコンテキストファイルを整備し、プロジェクト全体で共有・再利用する形へ移行しつつある。

　さらに、AIモデル単体の知識に依存するのではなく、GitHubやGitLab、Slack、Jira、社内Wiki、ライブラリの最新ドキュメントなど、外部システムからリアルタイムに情報を取得する動きも出ている。これは、モデルの知識の陳腐化やハルシネーションを防ぐ狙いがある。

　最近では、プロンプトそのものを「仕様書」（スペック）として記述し、AI自身にタスクを段階的な作業手順へ分解させながら実行する「スペック駆動開発」のような手法も登場している。

コンテキストを評価・テストする（Evaluate／Test）

　共通指示ファイルやSkillを変更した際、それがAIのコード生成へどのような影響を与えるかを自動で検証するフェーズだ。デボワ氏は、この「eval」（評価）こそが、AIエージェント時代に最も重要かつ見落とされやすい領域だと指摘する。

　例えば、「全てのAPIパスは『/awesome/』で始める」といった社内ルールをコンテキストへ記述した場合、本当にAIがそのルール通りコードを生成しているかを確認する必要がある。

　そのためにまず、コンテキストファイルの構文や長さ、形式が標準に沿っているかを自動確認する「リンティング」（Linting）を実施する。さらに、記述したコンテキストがAIにとって理解しやすいかを、別のLLMへ判定させるアプローチもある。

　加えて、生成コードを実際にサンドボックス環境で実行し、curlコマンドなどでAPI動作まで確認するE2E（エンドツーエンド）テストも必要になる。LLMを“審査員”（Judge）として使い、コード品質やルール順守を別のAIに評価させるアプローチも広がりつつある。

　ただしAIの出力は毎回同じとは限らない。そのため、「1回成功したから問題なし」と判断するのではなく、「5回実行して成功率を見る」といった、“確率”や“エラーバジェット”を前提にした運用が必要になるという。AI時代のCI/CDでは、「毎回同じ結果になる」という従来の前提が崩れ始めているためだ。

コンテキストを共有・配布する（Distribute）

　テストを通過した信頼できるコンテキストやSkill、Workflowを、組織内で再利用可能な形へ配布するフェーズだ。

　デボワ氏は、今後は“コンテキストそのもの”が、従来のソフトウェアライブラリのように管理される時代になると予測する。企業は、フロントエンド向け、セキュリティ向け、インフラ向けなど、用途別の“コンテキストパッケージ”を社内レジストリやマーケットプレイスで管理する可能性がある。

　ただし、その結果として、ソフトウェア開発のような「依存関係地獄」（Dependency Hell）も発生し得る。異なるコンテキストパッケージ同士が競合し、AIエージェントの挙動が不安定になるリスクがあるからだ。

　さらにセキュリティ面では、外部から取得したSkillやプロンプトを安易に読み込むことで、秘密情報漏えいや不正コード実行につながる危険性もある。そのため、コンテキスト専用のセキュリティスキャナーや、いわば“AI版SBOM”のような仕組みによって、「どのコンテキストが、どこ由来なのか」を可視化・検証する必要性も高まるという。

コンテキストの利用状況を観測し改善する（Observe／Adapt）

　配布したコンテキストが、現場で本当に効果を発揮しているかを監視・改善するフェーズだ。

　例えば、開発者がAIを利用した際のログを分析し、「AIがどの情報を不足していると頻繁に訴えているか」や、「どの場面で誤ったコード生成が起きているか」を特定し、コンテキストへフィードバックする。

　また、AIが生成したプルリクエストのレビュー履歴や、本番環境で発生した障害・バグのログを分析し、「なぜAIが誤ったコードを書いたのか」を逆算して、元のコンテキストやSkillを更新する流れも重要になる。

　加えて、プロンプトインジェクション対策として、AIへ入力されるコンテキスト自体を検査・遮断する『Context Filter』と呼ぶ概念をデボワ氏は提唱する。これは、Web Application Firewall（WAF）のように、悪意ある指示や危険なコンテキストがAIへ渡る前にブロックする役割を担う。

情シスは「AIの運用管理者」になる？

　デボワ氏の議論は、単なる開発者向けノウハウにとどまらない。企業の情報システム部門（情シス）にとっても示唆はある。

　今後、各部門が独自にAIエージェントやSkillを導入し始めれば、社内には“誰が作ったか分からないコンテキスト”や“検証されていないAI設定”が増えていく可能性がある。

　さらに、AI利用ログやエージェントログを分析し、「AIがどの情報不足で失敗しているのか」を特定しながら、コンテキストを継続改善していく運用も重要になるという。AIが生成したプルリクエストのレビュー履歴や、本番環境で発生した障害ログを分析し、「なぜAIが誤ったコードを書いたのか」を逆算して、元のコンテキストを改善する流れだ。

　デボワ氏は最後に、「LLMは単なるエンジンにすぎない。間違った燃料（コンテキスト）を与えれば、期待した性能は出ない」と語る。AI時代に企業が競争力を維持するには、“どのモデルを使うか”だけではなく、“どのようなコンテキストを与えるか”の重要性が高まる可能性があることを示唆している。

本稿は、AI Engineerが2026年5月3日に公開した動画「Context Is The New Code」を基に作成しました。