近藤 憲児

近藤憲児事務所 代表
AGI福岡 主催

• 九州大学大学院で数理学の修士（力学系理論・数理論理学）
• IIJ でテックリードとして IoT 基盤・Kubernetes as a Service を設計・実装
• スカイディスク で AIエンジニア → EM → AIテックリード。ML・組合せ最適化のプロダクト開発を牽引
• SaaS 企業の AI開発リードとして LLM プロダクト開発と AI駆動開発の推進を主導
• 並行して複数企業の LLM 実装支援・アドバイザリー・セミナー講師
• 特許第7755036号（LLM 関連発明）／ Udemy 講師（数学カテゴリ1位）／ 情報処理安全確保支援士 合格

今日の話は、この2つが交差する「AI駆動開発」の現場から見えてきたことが中心です。

バズワードに、寄り添う。

プロンプト／コンテキスト／ハーネス／ループ。この4つの言葉が実際に主張しているものに寄り添いながら、この2〜3年のAI開発を一緒にキャッチアップする時間にします。

「〇〇エンジニアリング」。正直、食傷気味かもしれません。SNSでは毎日のように新しい言葉が流れていきます。
でも、真面目に見るほど「なるほど」と思わされる。現場で薄々感じていたことの、再認識のきっかけになる。

外側の層は、内側の層を実行時に内包する。この断面をこの順にたどっていきます。問いの言葉が少しずつ変わっていくところに、あとで注目してください。

"The hottest new programming language is English."
いま最も熱いプログラミング言語は、英語だ。

Andrej Karpathy, X

技法は「発明する」段階から「目録（カタログ）を引く」段階へ。

目録化はガイドとしても整備された（OpenAI / Anthropic の公式プロンプトガイド、DAIR.AI “Prompt Engineering Guide” 等）。

かつての代表技法が公式に非推奨になり、
足した指示を外す段階に入った。

プロンプトエンジニアリングは、死んだのではない。
埋め込まれて、意識しなくなった。

• (a) 技法はモデルに内在化した（推論モデル）
• (b) 作成は自動化された（OPRO / DSPy / GEPA / ジェネレーター）
• (c) 上位概念に包摂された（入力全体をどう設計するか）

実例: 上手なプロンプトは「スキル」として資産化される時代に。自社リポジトリでは再利用可能スキル33本を運用。

橋渡し: 上手なプロンプトを再利用可能な形に洗練すると「スキル」になる。それはもう「AIに何を持たせるか」という、次の層の話。

「返信を考えて」だけでは、うまくいかない。

この、元になるやり取りが「コンテキスト」。（メール文面は例示のための架空のやり取り）

「どう指示するか」の次に、すぐ「どんなコンテキストを渡すか」が問題になる。

(1) そもそも入りきらない (2) 入れすぎると腐る（Context Rot）

「与える」の正体は、「選ぶ」だった。

大量の候補から「どれを渡すべきか」に当たりをつけて抽出する工程が前段に入る。
これがまさに検索であり、RAG（Retrieval-Augmented Generation）。

RAGの一番中心にある課題は、「大量のコンテキストからどう選ぶか」＝検索だった。

細かくて読めなくてよい。一つの関心をめぐって、これだけの技術が乱立した。

RAG の中心には、昔ながらの「情報検索」がいる。

→ その最前線を、次のページで。

「探す」から、知識そのものを構造化して持つへ。

理論的な源流には Palantir の Ontology（Objects / Links / Properties ＋ Actions）がある。検索では取れない「関係性・最新性・文脈の正しい理解」を、グラフ／オントロジー構造で持たせる。ナレッジマネジメントが、検索の延長として最前線に来ている。

• 標準化: 指示ファイル AGENTS.md は 6万超の OSS プロジェクトが採用
• MCP・goose とともに Linux Foundation 傘下（Agentic AI Foundation）へ寄贈

「AIに見せる文脈」が、インフラになった。

AIの一発の出力は、満足できないことが多い。

実装だと、具体的にはこうです:

コード規約に沿っていない ／ 既存コードと雰囲気が違う ／ リンターに引っかかる ／ 単純に間違っている ／ 冗長 ／ 動かすとエラーが出て、そもそも期待したものになっていない

いま、人は手作業でこうしている:

この手作業の仲介こそが、「AI はまだまだだね」と言われる風潮の一因。

LLMは確率的。だから、外側に検証を置く。

これは昔からある発想。数学の証明をLLMに書かせると間違うことがある。
Lean（証明支援系）なら形式的に正しいかを機械的に判定でき、「ここが間違っている」と返せる。
かつてエージェントの世界で「リフレクション」と呼ばれた考え方。

この路線が実際に到達した地点が AlphaProof。国際数学オリンピック（IMO）銀メダル相当で、証明の各ステップを Lean で形式検証する（Nature 掲載）。

同じ単語で、別のものを指している状態。

外向けは「ハーネス」、内部では分解した語で運用する。

実行基盤 ／ ガードレール ／ 自動検証ループ ／ 状態管理 ／ 観測基盤 （登壇者による整理）

Böckeler の整理: Guides = 行動前の誘導・feedforward ／ Sensors = 行動後の検知・feedback という制御工学の枠組み（martinfowler.com）。

「2025年がエージェントの始まりなら、2026年はエージェントハーネスの年になる」（Philipp Schmid, Google DeepMind）

"Humans steer. Agents execute." 彼らが書いたのはコードではなく、リンター・テスト・規約＝ハーネス（OpenAI）

「自分の宿題を、自分で採点させない。」

エージェントは自己の成果物を楽観的に評価する。だから generator と evaluator を分離する（GAN 着想。最終形は planner / generator / evaluator の3役）。単発実行（$9・20分）とフルハーネス（$200・6時間）で品質差を実証。銀行で数十年使われてきた maker-checker（作成者と承認者の分離）原則と同型。

定量でも: 観測可能性駆動でハーネスを自動進化させ、Terminal-Bench 2 の pass@1 を 69.7%→77.0% に改善。改善されたハーネスはモデル間で転移可能（Lin et al., arXiv:2604.25850）。

• ポストフックでリンターを必ずかける: LLMに毎回言うのではなく、外側で強制する
• パーミッションで危険コマンドを実行不可に
• ユニット・E2Eテストを必ず実行。DevinにE2Eを委譲
• MCPでデバッグコンソールを取得し、AIが自分で回す
• 最後まで実装させる /goal コマンド
• 自分自身には検証させない: 外側にガーディアン（別の検証役）を置く
• レビュー観点エージェント13本: どの観点を起動するかは LLM ではなくスクリプトで決定論的に判定
• 3モデル合意レビュー: 独立レビュー → 相互検証 → 合意した指摘だけ採用

事前のガイドより、事後のセンサーが、一番効く。

ハーネスは、開発だけの話ではない。

外側に検証を一つ置く。その入れ方が肝。

ハーネスが効くと、次に気づく。「起動すら、手作業だ」。

残るボトルネックは「キックのタイミングが業務時間に縛られる」ことだけ。だったら、そこも自動化したくなる。

キックの仕方は3つに整理できる（Anthropic の4分類のトリガーから登壇者が整理）: 人間のプロンプト ／ イベント ／ スケジュール（時間）

「エージェントにプロンプトを送る人間自身を、
プロンプトを送り込むシステムに置き換える。」

Addy Osmani によるループエンジニアリングの定義

ここでも、実践が先、命名が後。やってから、名前がついた。

ループの品質の下限は、評価器で決まる。（"A loop's floor is its evaluator"）

第3章の generator / evaluator 分離が、ループの前提条件になる。

「もう直接プロンプトを書かない。ループが Claude に何をすべきか判断している」

Boris Cherny（Claude Code 開発責任者、Osmani 記事内）

ループの特徴: 以前の結果が、また次の入力になる。

人間が、だんだん行動を見なくなる。勝手に作られていき、
「介入しなくても許せる範囲なら、それでいい」という状態になる。放っておくと、そうなる。

これらは独立のリスクではなく、連鎖して現れる。

これにどう向き合うかは、これからの課題。

では、人間の役割は何か？

• ここまで来ると「エンジニアもいらなくなる」と素朴に思ってしまう。Devin が出たとき、新人エンジニアと Devin が比べられる存在になった
• ループが根づいた組織で、新人は何ができ、何を学ぶべきか
• ループが回すコードの「正しさ」を、人間はどう確信するか
• ハーネスやループの設計にはまだエンジニアリングが要る。だが、その設計自体も AI の支援で作っている。この再帰をどう捉えるか

私が新人の頃、メモ帳で Java を書かされました。IDE の支援なしで。あそこで身についたものは、確かにある。
ただ、あの練習に込められていた「これが基礎だ」という感覚と、いまの時代の感覚は、少しずれてきているのかもしれない。
……それでも、では今の新人に何を教えるかと考えると、案外あれと同じことをするのではないか、とも思うのです。

自分でも、まだうまく表現できていません。
だから、一緒に考えたい。

置き換わったのではなく、内側に折り畳まれた。

ループが1周回るあいだに、その中でハーネスが実行を制御し、コンテキストが組み立てられ、プロンプトが送られている。
エンジニアの仕事は、コードを書くことから「AIが仕事をするためのループとハーネスを設計すること」へ移りつつある。