AIコーディングエージェントの普及に伴い、従来のコードではなくコンテキストがソフトウェア開発の中心になりつつある現状を解説する。DevOpsの概念を応用し、コンテキストの生成、テスト、配布、監視というコンテキスト開発ライフサイクルを提唱し、プロンプトや文脈をエンジニアリング的に管理・運用する手法について考察している。
コンテキスト開発ライフサイクルの幕開け
早く始めたい方が何人かいらっしゃるようですね。この機会にアーキテクトトラックを公式にオープンしたいと思います。トラックのホストがいないので、私自身で行います。本日はお越しいただきありがとうございます。すでに素晴らしいカンファレンスを体験されていることと思います。こんなにたくさんの方にお集まりいただき驚いています。始める前に、この会場でAIコーディングエージェントを使ったことがある方は手を挙げてください。はい、下げてください。使ったことがない方は手を挙げていただけますか。
なるほど、私と同じような方々ですね。完璧です。
さて、コンテキストは新しいコードである、あるいはコンテキスト開発ライフサイクルについてお話しします。AIエンジニアリングの分野で毎回違うテーマで話す機会をいただき、光栄に思っています。今回は少し先を見据えた内容です。まだ洗練されたアイデアではなく、すべてが完璧に揃っているわけではありませんが、そもそもAIの分野で完璧なものなどあるのでしょうか。
では始めましょう。皆さんは現在、プロンプトを使ってバイブコーディングを行っていると思います。私自身、もうコードに直接触れることはほとんどありません。ただAIに何か違うことをするように指示するだけです。ですので、コンテキストは生成されるものだからこそ、それが新しいコードであると言えるでしょう。
もう少し進んだ話をすると、私にはある傾向があることに気づきました。ヘルパーやその他の要素を含む大きなコードの塊を使用していたのですが、それらを単なるスキルに変えてしまったのです。私たちの製品にも、AIエージェントからのオンボーディングとしてその機能がありました。人々はPythonやNodeJSなど様々なものを使い、パッケージングにも異なるツールを使用しています。これを実際にコーディングするのは不可能ですし、膨大な作業が必要になります。しかし、スキルとして、まず彼らのパッケージマネージャーが何であるかを把握し、次にエコシステムが何であるかを把握し、そしてユーザーと一緒にこの手順を実行してください、と指示するだけで、私たちがコーディングできる以上の多くの問題を解決できました。これもまた、コードがスキルとして、そして再利用可能なワークフローとしてコンテキストへと戻っていく形の一例です。この考えを皆さんと共有したいと思います。
私は物事を並行して考えるのが好きです。2009年、この会場にDevOps関係者がいるかどうかわかりませんが、私が運用がもっと開発のようになったらどうなるだろうか、と問いかけた時期がありました。そこからコラボレーションやデプロイメントといったものが生まれました。そして去年あたりから、もしコンテキストがコードだとしたら、これをどうやって一貫した方法で扱えばいいのだろうかと考えるようになりました。
つまり、ソフトウェア開発ライフサイクルがあるなら、コンテキスト開発ライフサイクルはどのようなものになるのか、ということです。私たちは基本的に別の場所に移行しています。それはコードではなくコンテキストです。それはどう見えるのでしょうか。DevOpsの背景を持つ私としては、当然ながら無限ループを思いつきました。全体的なアイデアとしては、私たちが大量のコンテキストを生成し、次にそのコンテキストをテストし、同僚や組織の他の部門にコンテキストを配布し、それが機能するかどうかを監視し、機能しない場合や機能する場合は適応してコンテキストを再生成し、そこからさらに進んでいくというものです。これが今日お話しするループであり、いくつかの例を交えながらステップバイステップで説明していきます。
コンテキストの生成
まずは生成についてです。皆さんはプロンプトを書いているので、おそらくこれが一番馴染みのあるものでしょう。皆さんは人間によるコンテキスト生成器としてテキストを入力していますよね。私は、AI Engineerカンファレンスでの私の登壇時間を教えて、とAIに尋ねただけで、AIがウェブサイトから情報を取得し、あなたの登壇時間はこれですと教えてくれたことに本当に驚きました。ただ、私が与えたコンテキストは、私がパトリックであることなど、非常にシンプルなものでした。これが皆さんも普段の環境でよく行っていることでしょう。
もう少しレベルアップすると、プロンプトを書くのが面倒になり、再利用可能なプロンプトが欲しくなります。コーディングエージェントの種類によっては、これを指示と呼ぶこともあります。幸いなことに、agent MDのような形で少し標準化が進みつつあります。未だにclaw MDと呼んでいるのには不満がありますが、とにかくイメージは掴めるでしょう。私たちが作っているのは、再利用可能なプロンプト、再利用可能なコンテキストの断片です。
また、他のコンテキストを取り込むこともできます。日常的に使用しているライブラリのドキュメントがあれば、それを取り込みたいと思うでしょう。LLMは最新のドキュメントを持っていないかもしれず、幻覚を起こす可能性があるからです。バージョン2なのかバージョン3なのか分からないため、コンテキストを与えてドキュメントをダウンロードするように指示します。エージェントが最適化されていれば、そのバージョンのライブラリに向けたコード生成をよりうまくやってくれるはずです。これも、より良いコンテキストを獲得し、ライブラリからコンテキストを作成する一つの方法です。
もちろん、あらゆる場所からコンテキストを取り込む機能についても触れなければ不完全です。MCPは非常に重要な役割を果たしています。GitLabやGitHub、Slackなど、あらゆる場所からコンテキストを取得します。チケットでさえもコンテキストを作成しており、作業を進めながらそれを取り込んでいます。
そしておそらく最新のアプローチは、プロンプトを仕様書として書き始めることです。仕様駆動開発と呼ばれるもので、エージェントがそれを計画モードへと分解し、段階的なプロンプトに変換して実行していくというものです。この分野では多くの生成が行われています。ごくシンプルに言えば、これが皆さんに最も近いものでしょう。
コンテキストのテストと評価
しかし、これらすべてのコンテキストを入力し作成する際、もしcloud MDの2行を変更した場合、その影響を把握しているでしょうか。なんとなく良さそうだからやってしまえ、という感じでしょうか。物事をどうテストするかを考えなければなりません。コードとコンテキストがあるというだけの話ではありません。影響を確認するためにテストを書く必要があります。新しいコーディングエージェントを使ったとき、その行がまだ機能するかどうかはわかりません。AIエンジニアリングの世界では新しいことではありませんが、AIを使ったコーディングの世界では、コードコンテキストのためのテストである評価を書き始めることはまだそれほど一般的ではありません。
少し読みにくいかもしれませんが、並行して考えてみましょう。コードにはさまざまなレベルのテストがあります。最もシンプルなものはリンティングで、IDEに波線が表示されて、文法が間違っている、あるいはもっとうまく書けるといったことを教えてくれます。ここにあるのはスキルの検証の例で、説明文が必要であり、長さの制限があるということを示しています。つまり、この場合のコンテキストのフォーマット仕様に従って検証しているのです。実行可能なシンプルなリンターのようなものです。
さらに他のこともできます。コーディングにおける適切な例えが見つからないかもしれませんが、Grammarlyのようなものだと考えてください。コンテキストを書いたとき、エージェントはあなたが書いたものを本当に理解できるのでしょうか。2単語しか書かなければ、コンテキストを理解するのに十分な情報量とは言えません。
そこでできるのは、このコンテキストを与えられたとき、あなたはこれを理解できますかとAIに尋ねることです。すると、明確に書かれていない、完全ではない、必要な要素が欠けている、といったフィードバックを得ることができます。このようにツールからフィードバックを得られるため、コンテキストを書くたびに、ここを直した方がいいと教えてくれるGrammarlyのような存在を持つことができます。私が音声でコーディングするのが好きなのはそのためです。なぜか入力するよりも音声の方が詳細に語れるのです。タイピングは苦手で、何年経っても人差し指2本で打っています。でも話しているときは、画面に文章が浮かび上がるのを見ながら、良いコンテキストを作るのに役立っています。
また別の種類のテストもあります。
cloud MD、あるいはagent MDと呼ぶべきかもしれませんが、そこに、すべてのAPIエンドポイントは接頭辞としてawesomeを使用しなければならない、と記述したと想像してください。会社やチームに何らかの規約があるのは素晴らしいことです。そして、ユーザーを保存する新しいエンドポイントを追加して、というプロンプトを出したとします。皆さんは、生成されたコードが当然のようにスラッシュawesomeスラッシュuserとなっていることを期待するでしょう。これをテストする方法は、生成されたコードが実際にスラッシュawesomeで始まっているかどうかをLLMに尋ねることです。正規表現を使って行うこともできますし、これはあくまで例ですが、自分の基準に基づいてコードを判断し、正しいことを行ったかどうかを尋ねることができます。
もし上記のコンテキストなしで同じ質問をしたとしたら、URLの接頭辞にawesomeを付けるLLMは存在しないでしょう。ここに会社やチーム固有のルールが関わってきます。だからこそ、それが機能するかどうかを確認するためにテストを書くのです。GeminiはCopilotなどとは異なる反応を示すかもしれず、会社内でコンテキストをより切り替えやすくする必要があります。これを使ってテストを実行すれば、実際にその違いを見分けることができます。
そして全体的なテストスイートを作成することができ、これはユニットテストのようなものだと言えます。こうしたテストをいくつも用意しておき、生成されたものが良いコードか、ルールに従っているか、すべて問題ないかを教えてもらうのです。この場合、インフラストラクチャーアズコードのような側面もあります。コードだけである必要はなく、設定ファイルなどさまざまなものが対象になります。ここには読みにくいですが、私が毎回実行している基準のリストがあります。
しかし、エンドポイントがスラッシュawesomeスラッシュuserを含んでいるかどうかをテストしたい場合、単にコードをチェックするだけでなく、実際に動かしてテストしたいはずです。裁判官となるLLMにツールを与え、それがエージェントとなってサンドボックス内で実行できるようになれば、実際にcurlコマンドを実行することも可能です。LLMを裁判官としてツールと結びつけることで、多数のテストを実施できます。この場合、ファイルを見るだけでなく、本来の動作をすべて含めて実行するため、事実上のエンドツーエンドテストになります。
そして、リポジトリの特定のコミットに対してこのシナリオを実行し、このコンテキストが変化をもたらしたかどうかを確認することができます。つまり、リポジトリ内でコンテキストをコミットしながら、こうした仕組みを構築していくのです。
テストが機能しているか、何が欠けているかというフィードバックが得られるようになれば、コンテキストを最適化することができます。これをコードアクションのようなものに組み込み、LLMから得たすべてのフィードバックを活用して、このコンテキストを修正し改善せよ、と指示できます。コーディングの改善と同じように、コンテキストをテストするという考え方にシフトしていくのです。
テストと最適化ができるようになると、まず考えるのは、これをCI/CDシステムで実行できないかということでしょう。すべてのテストスイートを実行する場所として完璧ですよね。しかし、評価を実行する場合、少し奇妙なことが起こります。一度実行し、もう一度実行すると、同じ結果にならないかもしれません。非決定的な性質を持っていることを思い出してください。
ですから、一度実行して合格したかどうかだけで判断することはできません。それではデバッグのしようがありません。5回実行して、そのうち何回成功したかと考えるべきです。あるケースでは常に100パーセント成功するかもしれませんが、別のケースではそうならないかもしれません。コンテキストをどう変更するかによって、どのテストが成功するか影響を受けます。個人的には、これをエラーバジェットとして考えるのが役立つと感じています。本当に重視しているテストセットに対してエラーバジェットを設定し、最小限の失敗しか許容しない一方で、他の部分はよしとするのです。これがコンテキストのテストの考え方です。常に厳密なテストができるわけではなく、異なるアプローチが必要になります。
コンテキストの配布とパッケージ化
さて、テストが何をもたらすかをご理解いただけたかと思いますので、次は配布についてです。すでにリポジトリにコンテキストをチェックインしている方もいるかもしれませんね。それは素晴らしいことです。突然コンテキストが利用可能になり、同僚がチェックアウトして、摩擦なしにプッシュしたり共有したりできます。
しかし、私たちはこうしたものを行うための別のメカニズムを持っていました。複数のプロジェクトやチームにまたがって再利用したいコンテキストがあると想像してください。そこにはライブラリという概念がありました。もしコンテキストの一部をパッケージ化し、ガイドラインやフロントエンドなど、そのプロジェクトに必要なコンテキストをインストールできるとしたらどうでしょうか。
さらに一歩進めて、どんなパッケージが存在するかをどうやって見つければいいのでしょうか。それがレジストリです。現在、マーケットプレイスにスキルやTesslのレジストリのようなものが登場しているのは驚くことではありません。そこでは数多くのスキルを見つけることができます。しかし現実として、心からの意味で言いますが、スキルの99.9パーセントは使い物になりません。
それでも、他人が何をしているかを見て学ぶのには役立ちます。ただ、そこに評価セットを適用した場合、品質基準を満たしているものはほとんどありません。これは今後改善されていくでしょうが、多くのスキルや要素を自分たち独自のレジストリに置きたいという傾向も見られます。
これについては後でまた触れますが、全体像が見えてきたと思います。スキルにはコンテキストだけでなく、スクリプトやドキュメントなどさまざまなものが含まれます。これがパッケージフォーマットになるのでしょうか。おそらくプラグインやMCPも含まれるようになるでしょう。このようにスキルに標準化の波が来ているのがわかります。この概念が登場した途端、すべてのコーディングエージェントが、人々がコンテキストを配布するためのパッケージフォーマットのようなものとしてこれをサポートすると宣言しました。
一つのコンテキストを持つと、そこには依存関係が生じます。残念ながら、コンテキストにおいても依存関係地獄が起こるでしょう。フロントエンド用のものをダウンロードしたら、Reactコンテキストパッケージの中身と競合しているかもしれません。そうした問題にも対処しなければならなくなります。ライブラリのバージョンやコードのバージョンをミラーリングし、コンテキストのバージョンと連携させるようなパッケージも見られるようになっています。
そしてもちろん、パッケージが存在し、人々がレジストリに何かを公開するようになれば、セキュリティが必要になります。OpenClawには感謝しています。見知らぬ人から提供された、安全かどうかわからないものを自分のラップトップで実行できる状態にあるため、より安全な仕組みが必要であることに誰もが突然気づきました。Snykはコンテキストをスキャンする方法を持っています。認証情報の処理やサードパーティの要素の露出などを確認します。コンテキストに対するこうしたスキャナーも登場し始めています。
セキュリティについて考えるとき、誰がこのスキルを作ったのか、どのように作られたのか、どのモデルで作られたのかといった情報が重要になります。つまり、パッケージングでいうところのSBOMのように、私たちが投入しているコンテキストのパッケージにおけるAI SBOMのようなものを捉える必要があるのです。
コンテキストの監視とセキュリティ
生成し、評価し、配布するという流れを追ってきました。次は監視に移りましょう。
他人のためにスキルやコンテキストのライブラリを作成するとき、それはSlackでコピペするようなレベルの話ではなく、ライブラリのように他人が使えるものとして保守したい場合の話です。人々がそれを使い始めたとき、それがまだ機能しているかどうかをどうやってフィードバックとして得るのでしょうか。フィードバックを得るのに最適な場所は、実はエージェントのログを見ることです。
ある開発者がプロジェクトでコーディングしていて、エージェントが思い通りに動かないと想像してください。彼らはそれを自分たちのコンテキストに追加するかもしれません。それは問題に直面した際のTDDのようなもので、素晴らしいことです。厳密にはTDDではありませんが、言いたいことはわかるでしょう。では、チームや組織の規模で毎回エージェントがこの部分が足りないと言っているログを見て、それを表面化させたらどうでしょうか。全員がこの部分を欠いているなら、そのためのコンテキストを作成し、全員に配布すべきです。そうすれば、改善の影響が全員に及びます。
幸いなことに、agent MDのようにログの標準化も進みつつあります。ですから、エージェントがコンテキストを使用しているか、あるいは欠落しているかを確認するためのフィードバックチャネルの一部としてログを読み取ることができます。
不完全なプルリクエストに対するフィードバックも、コンテキストに対するフィードバックになります。そのプルリクエストは特定のコンテキストに基づいて作成されたからです。もしこれが間違っていると指摘されたら、プルリクエスト上で議論を続けることもできますし、コンテキストを改善して次のイテレーションで問題が解決されるようにし、同じ問題に再び直面しないようにすることもできます。
コンテキストから生成されたコードを本番環境で実行する場合はどうでしょうか。プルリクエストのレビューでいいねやダメだというフィードバックを出しますが、実際のフィードバックは本番環境で実行されたときにも得られます。これは実際にコードを計測し、ラッパーのように本番環境にプッシュするツールです。失敗したときには、変更されたこのコード部分が失敗していると教えてくれます。このケースでは入出力が何か間違っていたようです。
次回以降、本番環境のフィードバックループで再びこの問題に直面しないように、これに対するテストケースを作成できるでしょうか。
これらはコンテキストの欠落や改善といった比較的些細なことですが、エージェントを実行する場合、CI/CDでのスキャンのようなものが必要です。本番環境で実行されているときに、何かおかしなことをしていないかを確認しなければなりません。私自身、サンドボックス化したエージェントを色々試してきましたが、エージェントは非常に機知に富んでいます。これを実行してシステムから抜け出す有用な方法を見つけて、環境変数を使うのか、なるほど、じゃあシークレットを削除してみよう、メモリファイルを見てみよう、といった具合です。ですから、エージェントが何をしているにせよ、それを追跡できる方法を確実に持っておく必要があります。
またスライドについてお詫びしますが、要点はエージェントが内部で実行されるサンドボックスを持てるということです。しかし、皆さんのコーディングエージェントは、デフォルトでは何の制限もなくagent MDやskill MDを読み込みます。ダウンロードすればすぐに読み込まれます。ですから、サンドボックスだけではそれをフィルタリングできません。別の方法が必要です。私はこれをコンテキストフィルターと呼んでいます。ウェブアプリケーションファイアウォールのようなものと考えてください。直接入ってくるパターンやプロンプトインジェクションなどをフィルタリングするのです。
そしてそれをさらに進めると、ハーネスエンジニアリングについての議論も多くあります。ハーネスエンジニアリング自体にも、ログやトレース、フィードバックを見るための完全なオブザーバビリティが備わっています。トレーニングのためだけでなく、自分のシステムを運用する上でも非常に役立ちます。
組織全体でのコンテキスト活用へ
今日お話ししたかったのはこうした要素です。多くの人にとって、コンテキストを作成し、テストするというループがあるでしょう。これをライブラリ作成者のツールループと考えてください。
そしてこれを企業に導入すると、組織的なループが生まれます。私がライブラリを作り、他の誰かがそれを使う。それが有用かどうか、まだ機能しているかどうか、他のすべての部分で機能しているかどうかを監視するのです。これはSonarのような、コンテキストのためのCI/CDモデルでの改善ループのようなものです。
現在、皆さんはおそらく個人モデルで多くのことを行っているでしょう。自分自身のマークダウンを改善し、磨き上げ、作り込んでいます。これをチームでもっと行い始めたらどうなるでしょうか。脅威を感じたらコンテキストを追加する、それを反射的な行動にするのです。これを複数のチームに展開し、フライホイールを回し始めたらどうでしょうか。ここで修正すれば、他のチームもそれを再利用できる。そうやって組織全体にスケールアウトしていくのです。
LLMやコーディングエージェントについては多く語られており、私もそれらが大好きですが、私の見方ではそれらは単なるエンジンにすぎません。エンジンに間違った燃料、つまりコンテキストを与えれば、パフォーマンスは発揮できません。私にはLLM自体をどうこうすることはできません。コーディングエージェントを使い、与えられたものを使うだけです。しかし、自分のコンテキストを最適化することはできます。それが今日お伝えしたいメッセージです。ただコピー＆ペーストしてうまくいくことを祈るのではなく、よりエンジニアリング的なアプローチでこれを行うべきです。
もしこの講演を気に入っていただけたら、LinkedInで繋がってスライドを受け取ってください。良いフィードバックも悪いフィードバックもお待ちしています。これらの一部を実装したTesslを試してみたい方はぜひ使ってみてください。そして、もうこれ以上カンファレンスは必要ないかもしれませんが、もし別のカンファレンスにも興味があれば、私がコンテンツをキュレーションしているAI DevConが6月1日と2日にロンドンで開催されるのでぜひお越しください。私からは以上です。いくつか質問を受けられるかもしれません。
質疑応答
質問はありますか。
はい、どうぞ。
マイクですね。私がテストしていることの一つに、コンテキストの形式、あるいは評価の形式として一貫性を生み出す機能があります。非常に大まかな計画の定義が与えられたとします。それをエージェントのシステムに入れて、非常に明確な定義に変換しようとし、それを並行して実行させます。その結果、どれくらいの頻度で同じ明確な定義が得られるでしょうか。もし結果がバラバラなら、元の定義が非常に貧弱だったということで、基本原則やアーキテクトのところに戻る必要があります。しかし、すべて同じ結果になれば、それはおそらくかなり良い定義であり、下流のプロセスに進むことができます。そこで質問ですが、単なるコードや典型的な評価以外に、有用だと思うコンテキストのソースやコンテキストの生成方法はありますか。
あなたの少し特殊なケースに対する明確な答えは持ち合わせていないかもしれませんが、人々が過小評価している点について言及しておきます。すべてのコードを書く代わりにコンテキストを書くことで時間を節約できると考えていたはずです。しかし、これを厳密に行うなら、適切な評価を書くことに時間を費やすことになります。
正しく設定しようとしているプロンプトは一つだけではないからです。評価のためのすべてのプロンプトを用意する必要があり、高度なスキルを持つ人たちはほぼ独自のプロセスを持っています。彼らはビジネスケースに合わせて適切な評価を構築するために、その上に独自のプロセスを構築しているのです。ですから、多くの労力がかかることになります。はい、良い質問でした。ありがとうございます。
他に質問はありますか。
なければ、私はこの辺りにいますので声をかけてください。Tesslのブースにも行く予定です。本日はどうもありがとうございました。次のスピーカーに場所を譲りたいと思います。ありがとうございました。
コメント