コードより重要視される「文脈」— Patrick Debois氏、Tessl

コードより重要視される「文脈」— AI エンジニアリングの新たなパラダイムシフト

Patrick Debois 氏（Tessl CEO）は、現代の AI エンジニアリングにおいて「コードそのもの」よりも「文脈（コンテキスト）」が最も重要な資産へと変貌しつつあると断言します。従来のソフトウェア開発ライフサイクル（SDLC）を模倣した「文脈開発ライフサイクル（CDLC）」の確立こそが、生成 AI の信頼性を高める鍵となるのです。

コードから文脈へ：新しい開発パラダイム

かつて私たちは、AI にコードを書かせるためにプロンプトを駆使していました。しかし、Patrick 氏は現在、「コンテキストは新しいコード」であると定義します。なぜなら、生成 AI の出力は、私たちが提供する文脈（プロンプト、ドキュメント、ルール、スキル定義など）によって直接決定されるからです。

「コンテキストが新しいコードである理由は、それが生成されるからです」

従来の「コードの断片」や「ヘルパー関数」を再利用する発想は、もはや不十分です。代わりに、Python や Node.js といった言語固有のパッケージ管理ツールに依存せず、「スキル（Skill）」という概念で文脈をパッケージ化する必要があります。

例えば、「相手のパッケージマネージャーを特定し、エコシステムを確認し、ユーザーと一緒に手順を実行する」といった指示を、言語のコードではなく、エージェントが理解できる文脈として定義します。これにより、特定の言語やツールの制約を超えた、より汎用的で強力な問題解決が可能になります。

テスト駆動型文脈開発：Evals の重要性

文脈を設計する際、単にプロンプトを書くだけでは不十分です。コード開発における「Lint」や「Grammarly」、そして「テスト駆動開発（TDD）」に相当する仕組みが不可欠となります。

1. Lint と Grammarly：構文と品質のチェック

まず、文脈のフォーマットが正しいか検証する必要があります。例えば、「説明は必ず記載すること」「文字数はこれ以下にする」といったルールを設け、IDE が波線を表示するような自動検証ツール（Lint）を実装します。

また、文脈がエージェントに正しく理解されているかを問う「Grammarly」的なアプローチも有効です。単なる命令ではなく、「この文脈に基づいてどう解釈するか？」と問いかけ、エージェントからのフィードバックを得て、曖昧な部分を修正します。

2. LLM を判事とする Evals（評価）

より高度な検証には、生成されたコード自体をテストする「Evals」が必要です。これは、LLM を「判事」として機能させます。

「すべての API ポイントは接頭辞として awesome を使う必要があります。このルールに従ってコードを生成したか、LLM に確認させるのです。」

従来の正規表現（Regex）でのチェックでは対応できない、文脈やビジネスルールの適合性を、LLM が生成されたコードを読み解いて判断します。これにより、企業固有の規約やチーム特有のルールが守られているかを自動的に検証できます。

3. エンドツーエンドテストとエラーバジェット

単にファイルの中身を見るだけでなく、実際に実行して動作を確認する「エンドツーエンドテスト」も重要です。LLM にツール（例：curl コマンド）を与え、サンドボックス内で実際に API を叩き、期待通りのレスポンスが返ってくるか検証します。

ここで注意すべきは、LLM の非決定性（不確実性）です。同じプロンプトでも結果が毎回異なる可能性があります。そのため、一度の実行で合格・不合格を判断するのではなく、複数回実行して成功率を測る必要があります。

「エラーバジェット（許容失敗率）の概念を導入しましょう。重要なテストには 100% の成功率を求め、それ以外は一定の失敗率を許容する枠組みが必要です。」

CI/CD システムにこの仕組みを組み込み、文脈の変更がシステム全体の安定性を損なわないように管理します。

文脈の配布とレジストリ：組織資産としての管理

優れた文脈は、個人のものではなく組織全体で共有・再利用されるべき資産です。Patrick 氏は、これを「スキル」としてパッケージ化し、「レジストリ」で管理するモデルを提案します。

スキルとパッケージ管理

文脈の断片（プロンプト、ドキュメント、スクリプト、MCP 標準など）をパッケージ化することで、他のプロジェクトやチームでも再利用可能になります。これは、従来のライブラリ管理に似ていますが、依存関係の複雑さ（「依存地獄」）への対処も必要です。

「フロントエンドのガイドラインや React の文脈と競合しないよう、バージョン管理を徹底する必要があります。」

セキュリティと SBOM

外部から取得したスキルやコンテキストにはセキュリティリスクが伴います。Snyk などのツールでスキャンを行い、認証情報の漏洩や悪意のあるコードを検知します。

また、パッケージの透明性を高めるため、AI 版の SBOM（ソフトウェア部品表）の導入も重要です。「どのモデルで構築されたか」「誰が作成したか」というメタデータを文脈に付与し、信頼性の高い文脈のみを採用する基盤を整備します。

観測と適応：フィードバックループの確立

文脈開発は、配布して終わりではありません。実際の運用での挙動を監視し、改善し続けることが重要です。

ログからの学習

エージェントが「この部分が見当たらない」と報告するログや、不完全な PR（プルリクエスト）のフィードバックを収集します。組織全体で同じ問題が発生している場合、それは文脈に欠陥がある証拠です。その情報を可視化し、新たな文脈を作成して配布することで、組織全体の生産性を底上げできます。

本番環境への監視と自動修復

コードが本番環境で実行された際のエラーも貴重なフィードバック源となります。エラー発生時に「この部分のコードに問題がある」と通知を受け取れば、それをテストケースとして登録し、次回から同じミスを防ぐ文脈を自動生成する仕組みが構築できます。

さらに、サンドボックス化によるセキュリティ検証も重要です。「システムから抜け出す方法を探せ」と指示してエージェントの挙動を検証し、環境変数やシークレットへの不正アクセスを試みるリスクを事前に排除します。

まとめ

Patrick Debois 氏が提唱する「文脈開発ライフサイクル（CDLC）」は、生成 AI を単なるツールから、堅牢なソフトウェアエンジニアリングの原則に基づいたシステムへと進化させる転換点です。コードの記述よりも、「文脈をいかにテストし、管理し、最適化するか」というプロセスこそが、現代の AI エンジニアに求められる核心スキルとなります。

企業においては、AI エージェントの信頼性を高めるために、この「文脈資産」を体系的に管理・評価するインフラ整備が急務です。DevOps の延長線上にある「AI Ops」への移行は、もはや選択ではなく必須の課題なのです。