KubeCon Europe 2026、AIがコードを書く時代にはコードではなくコンテキストが重要になると訴求するセッションを紹介

KubeCon Europe 2026と併催されるミニカンファレンス「Agentics Day:MCP + Agents」から、Tesslのデベロッパーリレーションの責任者、Patrick Debois氏が行ったセッションを紹介する。TesslはSynkを創業したGuy Podjarny氏が創業したベンチャーだ。生成AIのコーディングアシスタントがソースコードを書くようになった時代に求められるのは、コードそのものではなく「何を作りたいのか？」というコンテキストが重要だと訴求するセッションを紹介する。

●動画：新しいAIコーディング基盤

プレゼンテーションを行ったPartick Debois氏が所属するTesslは、エージェントがコードを書く時代に向けた開発基盤の提供を目的として作られたベンチャーだ。コードをエンジニアが書くのではなく生成AIが書く場合に最も重要になるのは「何を作りたいのか？」という意図、コンテキストであるというのがTesslの企業としてのバックボーンである。Tesslは生成AIがデベロッパーのコンテキストと利用するオープンソースソフトウェアの仕様やバージョン、依存関係などを正確に理解して利用できるようにするためのツール群を開発し、提供している。

Tesslが提供している主なソフトウェアは「Tessl Spec Registry」と「Tessl Framework」で、Spec Registryはオープンソースの使い方をエージェントに教えるレジストリ、Frameworkはエージェントを仕様（Spec）で制御する開発フレームワークであるという。ここでプレゼンターの所属する企業を説明するのは、プレゼンテーション自体がその意図に基づいて作られているからだ。

プレゼンテーションを行うDebois氏

セッションのタイトルは「AI Coding Fabrics - Context Development Lifecycle」というもので、生成AIによるコーディングを支えるコンテキストを中心としたソフトウェア開発サイクルを俯瞰するという内容だ。自社プロダクトの宣伝をするのではなく生成AIを利用する際のツールや考え方を網羅的に紹介することで、コンテキスト主体の開発スタイルを推奨し、Tesslのプロダクトに誘導するという方法をとっている。

コンテキストが新しいソフトウェアコードであるという主張

このスライドではVibe Codingとエージェントに与えるプロジェクト開発の要旨を記載したマークダウンファイルを例に挙げて、生成AIが主体となる開発方法を説明。Vibe CodingについてはすでにPoCに必要なコードを生成AIに全部書かせてソフトウェア開発サイクルを回すという事例があるほどに正しく使えば、実用に耐えうるレベルに到達していると言える。以下の西川和久氏のインタビューを参照して欲しい。

●参考：生成AIのPoCを専門にやる凄腕エンジニアにインタビュー。企業がPoCを専門家に頼む意義とは？

Debois氏は2009年頃に流行った運用エンジニアがデベロッパーのように仕事をするという流れと並行して、コンテキストを書くことがソフトウェア開発と同等になるという流れが2025年に起こっていると紹介。地殻変動的な変化が現在進行形でしているとして、この流れは止められないと語った。

運用にデベロッパーの手法を取り入れることと同じインパクトが生成AIとコンテキストによる開発と訴求

そしてコンテキスト中心としたソフトウェア開発のライフサイクルを紹介。

コンテキスト主体のソフトウェア開発サイクルを紹介

ここでは「何を作りたいか？」という意図を暗示的なものもすべて明示的に表現することでコードを生成し、テストを実施、できあがったものをビジネスにパッケージとして実装し、その性能などを観測するという一連の流れである。スライドでは1～4のステップを繋ぐ矢印の向きが反対であるように思えるが、1から4にプロセスが流れるという意図はTesslのブログにも詳しく解説されている。

●参考：The Context Development Lifecycle: Optimizing Context for AI Coding Agents

この4つのステップ（Generate～Evaluate～Distribute～Observe）についてここから順に解説をおこなうというのがこの後の流れである。

4つのステップ（Generate～Evaluate～Distribute～Observe）を順に解説

最初に紹介したGenerateの例はClaude Codeに与えるプロンプトによってコードが生成されるというものだ。実際にこの例ではアムステルダムのKubeConで参加すべきセッションを教えて欲しいという内容で、大雑把なプロンプトではなく明示的に何がしたいのか、何をしたくないのかを指示している。

Claude Codeに明示的に何をしたいのか、何をしたくないのかを指示する例

プロンプト以外にも生成AIに与える指示としてAgents.mdという命名でMarkdown形式のルールを提示する方法もあると説明。

Agents.mdファイルでプロンプト以外の指示を与える例

またプロンプトやMarkdown以外にも、ドキュメントやGitHubのContext-hubといったサイトからの入力を使ってコードを生成するという方法論を紹介。ここではGitHub、context7.com、ref.toolsなどのサイトを紹介している。

プロンプト以外のコンテキストを提供するさまざまなサイトを紹介

またSpec Driven Development（仕様によって開発を行う方法論）を実装しているツールを紹介。ここではKiro、GitHubのSpec Kitを紹介している。すでにこの時点でVibe Codingが時代遅れであると言いたげな内容である。

生成AIが使う機能を定義するSkillsを紹介

ここで初めて自社のサイトを使って生成AIが利用する機能を定義するSkillsを紹介した。この例ではTerraformの使い方を明確に指示することで誤ったコードを抑止するという発想だ。

GrammarlyのようにSkillsの記法をチェックする例

次のEvaluateの例ではSkillの記法の評価にGrammarlyのような文法チェックを行うという手法を紹介。これもTesslのサイトのページを紹介している。

CI/CDについても評価を厳密に行うべきと提案

ユニットテスト、エンドツーエンドテストにおいても明確に何をするのか？ しないのか？ を明記することで評価が正しく行われると説明している。またCI/CDについても明示的に何を達成するべきなのか？ を評価するべきと説明し、ここでも人を介さずにタスクを生成AIによって実行させるヒントを提示している。

Anthropicが公開しているSkillの例を紹介

Distributeの例ではGitHubでのコード公開を紹介。ここではAnthropicが公開しているSkillに関する定義を例に挙げて紹いる。

MicrosoftのAgent Package Managerを紹介

次に紹介したのはMicrosoftが公開しているAgent Package Manager（APM）の解説ページだ。APMによってマニュアルで指示を与えるのではなく、SkillやPlug-in、厳密なコーディングルールなどを明示的に指示することで誤りを減らす方法となる。

Clude Codeが使うSkillsをマーケットプレイスとして提供するサイトを紹介

ここではclaudemarketplaces.comを紹介。このサイトはClaudeのコミュニティによって運営されており、Anthropicとは独立して運営されているという。

またセキュリティの観点からバイナリーではなくコンテキストのセキュリティスキャンが必要となると説明。AIに関する教育を行っている営利団体、Applied AI Instituteが提唱するAISBoM（AI Software Bill of Materials）を紹介。ここではAIが何から作られているのか？ を明らかにするべきと解説している。

Distributeの段階でAIのSBoMが必要となると説明

最後のEvaluateの段階ではAgentが実行結果として残すログやトレースを標準化するCognition.aiのサービスを紹介。

Cognition.aiのオブザーバビリティのデータ標準化案を紹介

Cognition.aiはDevinの開発元として知られている企業だが、ここではAgentのトレースを標準化するべくCursorやCloudflare、Vercelなどと協力して推進することを表明したブログを紹介。またEntire.ioが進めるエージェントのワークフローを可視化するサービスなども紹介し、AIそのものではなくAIが行った実行記録を人間が読み取れるようにするソリューションを紹介した。

Entire.ioのサービス、エージェントによるコミットを可視化

またHud.ioによるコードの速度低下やエラーを可視化するサービスも紹介し、エージェントが書いたコードが実際に何をしているのかを解きほぐすことでAIの成果物をエンジニアが理解可能にする必要があることを説明した。

Hud.ioのサービス、コードが何をしているのか？ をAIが判定するサービス

Hud.ioのサービスはコードの実行を可視化するというものだが、生成AIがコードを書き、その実行を別の生成AIが評価するという状況はエンジニアがAI同士を戦わせているという構図だろう。この時点ですでに人間のエンジニアは傍観者と言っても良いかもしれない。

他にもエージェントのサンドボックス化、コンテキストをフィルタリングするアプリケーションファイアウォールなども紹介。生成AIそのものの評価ではなく、入力されるプロンプトやコンテキストの評価、ガードレイルなどを紹介しているのが実践的と言えるかもしれない。

まだ解答が見つからない「コンテキスト中心の開発」の課題

最後にコンテキストを使った開発の課題についてざっと紹介。ここではコンテキストにカオスエンジニアリングを適用したらどうなるのか？ コンテキストの分析、A/Bテストは可能か？ エージェントが自律的に実行まで行えるのか？ エージェントがコンテキストに最適な言語を発明できるか？ などDebois氏自身が抱える課題を共有してセッションを終えた。

コンテキストが主体となる開発を網羅的に紹介し、さまざまなサービスを並べることである程度はコンテキストによる開発が可能であることを示唆した内容だったが、自社のサービスも紹介することでデベロッパーリレーションとしての責務は果たした格好となった。まだ解答が見つからない課題も多いが、どこが抜けているのか？ についても明らかにしている点は好感が持てる。

最後には「コーディングエージェントがエンジンならコンテキストは燃料である」というメッセージを伝えてセッションを終えた。

コーディングエージェントがエンジンならコンテキストは燃料