0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@furuse-kazufumi(古瀬 和文)

#43 2026年、業界はAIに「手綱」と「輪」を名付けた — harness/loop engineering の試作スタックをローカルに組み始めた話

0
Last updated at Posted at 2026-06-15

#43 2026年、業界はAIに「手綱」と「輪」を名付けた — harness/loop engineering の試作スタックをローカルに組み始めた話

はじめに：私が「使うのをやめた数字」の話から

この記事を書く準備をしていて、私はひとつ、使いたくてたまらない数字に出会いました。

「ある2026年の論文が、AIモデルを固定したまま"周辺の器"だけを変えて、最大10倍の性能改善を示した」

つかみとして完璧です。これから話す「ハーネス（器）」の威力を、一発で示せる。ところが一次情報をあたったら、その数字は 根拠不明 でした。論文は実在するのに、引用されていた著者名も「10倍」という数字も、その論文には 存在しなかった のです。だから私は、この数字を 捨てました。

なぜこんな後ろ向きな話から始めるのか。それは、この「捨てる」という作法こそが、本記事を通じて私がいちばん伝えたいことだからです。

異常にキャッチーな数字を見たら、勝った気になる前に必ず内訳を疑う。一次情報に錨を下ろす。

賢いAIは、知らないことすら流暢に語ってしまいます。雑に頼めば、賢いがゆえに勝手に補完して、こちらの意図とズレた場所へ全力で走っていく。だからこそ、人間の側に「ここは未検証だ」と線を引く目が要る——この記事は、その目を持った人間が、2026年のAIエンジニアリングの「次の名前」を、地に足をつけて検証していく話です。

（捨てた数字の詳しい検証は、第2章のあとの独立した節で全部開示します。先に作法を約束しておきたかったので、結論だけ冒頭に置きました。）

第0章 用語の地図 — prompt から loop までの階段

本題に入る前に、地図を広げます。

2025年、AI業界の合言葉は prompt engineering（プロンプトエンジニアリング） ——「LLMにどう頼むか」を磨く技術でした。やがてそれは context engineering（コンテキストエンジニアリング） ——「LLMに何を見せておくか」を設計する技術——へ拡張されます。

そして2026年、業界はさらに2つの名前を付けました。

  • harness engineering（ハーネスエンジニアリング） … LLMを包む「決定論的なランタイム層」を設計する技術。
  • loop engineering（ループエンジニアリング） … エージェントを「自律的に回るループ」として設計する技術。

ここで「発明したのはAIではなく人間（業界）だ」と先に断っておきます。タイトルで「AIが発明した」と書きたくなる擬人化は、事実を歪めます。名付けたのは、これから紹介する人間のエンジニアたちです。

この記事のコンセプトは、こうです。

業界が名付けたこの2つを、私は概念実証レベルで手元（ローカル）に置いている。ただし、私の設計図には、業界のモデル中心の解説図には載りにくい"もう1つの軸"がある。

その軸とは、手綱を握り続ける人間と、部下のように育てられるAIです。本記事では、(A) ハーネス、(B) ループ、(C) それを支える知識基盤、という3テーマを、私が実際に動かしている実装——RAPTOR（セキュリティエージェント）、llloop（自作ループハーネス・alpha）、RADコーパス + LLM Wiki（自前研究知識）——で検証します。

長い記事です（約2万字、20分コース）。要所に かみくだき（用語のやさしい説明）、閑話休題（箸休め）、honest disclosure（正直な内訳開示） を挟みます。疲れたら章の切れ目で一息ついてください。

prompt → context → harness → loop の流れ

AIエンジニアリングの「成熟度」は、2026年現在、おおむね次の階段で語られます。

  1. prompt engineering … 1回の指示文を磨く。
  2. context engineering … LLMの視野（コンテキストウィンドウ）に何を載せるかを設計する。
  3. harness engineering … LLMの「外側の器」を設計する。ツールの呼び出し、権限、実行、結果の差し戻しを担う層。
  4. loop engineering … その器を「自律的に回るループ」として設計する。

prompt → context → harness → loop の階段（2025→2026）

↑ 段を上がるほど「LLM の外側」を設計する。2025 の prompt / context（何を頼むか・何を見せるか）から、2026 の harness（外側の器）/ loop（自律的な輪）へ。本記事はこの上 2 段の話。

ある解説メディアはこれを「第4のパラダイム」と呼び、LangChain（エージェント開発ライブラリ）は Agent = Model + Harness（エージェント＝モデル＋ハーネス） と要約しています（augmentcode.com の解説経由で確認した 二次情報。一次出典の LangChain 原文は本稿では未取得なのでヘッジします。以降この式を再掲するときも「二次」と付けます）。

かみくだき：「ハーネス」って何？

harness（ハーネス） は、もともと「馬具」や「（赤ちゃんやロッククライマーを安全につなぐ）安全帯」を指す英語です。

LLMは、ものすごく賢いけれど、放っておくと暴れたり、あらぬ方向へ走ったり、たまに地面のないところへ踏み出したりする「力の強い馬」のようなものです。その馬に 馬具（ハーネス） を付ける——どこへ行けるか、どのツールを使えるか、結果をどう持って帰るかを、馬具の側でカチッと決めておく。これが harness engineering です。

馬具のたとえは便利ですが、どこで壊れるかも言っておきます。本物の馬具は「物理的に動きを縛る」だけですが、LLMのハーネスは「縛る」だけでなく「結果を整形して馬の目の前に差し戻す」役割も持ちます。馬具に「次はこっちを見ろ」と景色を見せる機能が付いている、と思ってください。そこまで含めると、たとえはやや窮屈になります。

かみくだき：automation（自動化）と loop（ループ）はどう違う？

ここが loop engineering の核心です。タイトルで loop を「輪」と訳しましたが、これは「ぐるぐる同じ手順を回り続ける輪」のイメージから来ています。ただし、ただの輪ではありません。2026年6月のあるガイドが、その違いを切れ味よく定義しています。

「automation は一連の手順を実行する。loop は内部に意思決定を持つ。エージェントはゴールに到達したかどうかを能動的に判断している。」
（Data Science Dojo, Agentic Loops Explained: From ReAct to Loop Engineering (2026 Guide), 2026-06-09 / リンク）

平たく言うと——

  • automation（レシピ）：「卵を割る → 混ぜる → 焼く」。手順が固定されている。途中で「あ、卵が腐ってる」と気づいても、レシピ自体は止まりません。
  • loop（ループ）：毎周回ごとに「今どうなってる?」「ゴールに着いた?」「危なくない?」を 自分で確かめながら 進む。腐った卵に気づいたら、その場で「これは中止」と判断できる。

ここで1つ、論理の罠を先に潰しておきます。「loop は判断点を持つ」ことと「loop は安全だ」は別の話です。 automation が腐った卵で止まれないのは、automation の本質というより「判断点を置かなかった設計」の貧弱さです。逆に、loop でも判断ロジックが穴だらけなら同じ事故は起きます。判断"点"を持つことと、判断の"質"を保証することは別問題で、後者を担うのが後半で登場する safety層 です。この区別は、本記事を通じて何度か効いてきます。

同ガイドは、エージェントループの中身を Perceive（知覚）→ Reason（推論）→ Plan（計画）→ Act（実行）→ Observe（観測） の5段階の繰り返しとして描き、ループが成立するには「トリガー（きっかけ）」と「検証可能なゴール（verifiable goal）」の2つが要る、としています。

「検証可能なゴール」という言葉を覚えておいてください。後半で、Claude Code の /goal コマンドや、私の自作ハーネスの安全層に、そのまま効いてきます。

この章の honest disclosure

loop engineering 周辺の出典（Data Science Dojo、Medium記事、各種ブログ）は 査読論文ではなく実務ブログ です。定義（automation vs loop、P-R-P-A-O）は複数ソースで整合しているので「2026年に実務で流通した用語」として扱います。「権威ある学術定義」ではない、という温度感を保ちます。

🗨️ 「本を鵜呑みにするな」 — スナックバス江／フォビドゥン澁川（アル）

（閑話休題）実務ブログも、査読論文も、そしてこの記事も——鵜呑みにしない。「2026年に実務で流通した用語」と「権威ある学術定義」を取り違えない、その温度感だけは持ち帰ってください。

第1章【手綱 = harness】業界の定義、RAPTORという実物、そして"もう1つの軸"

1-1. harness engineering は誰が、いつ名付けたのか（一次情報で確認した）

ここは時系列が大事なので、一次情報をあたりました。

Mitchell Hashimoto 氏（HashiCorp 共同創業者、Terraform 共同開発者）が、2026年2月5日のブログ記事 My AI Adoption Journey で、この呼称を提示しています。重要なのは、本人の言い回しです。

「この分野に広く受け入れられた用語があるのかは分からないが、私はこれを harness engineering と呼ぶようになった。」
（mitchellh.com/writing/my-ai-adoption-journey、2026-02-05、本文を直接確認）

つまり Hashimoto 氏は「私が発明した」とは言っていません。「広く受け入れられた用語があるか分からないが、自分はこう呼んでいる」と、慎重にヘッジしています。だから本記事も「2026年2月ごろに業界で名前が付き始めた呼称」程度に留めます。

彼が説くハーネスエンジニアリングの中核原則は、職人芸のように具体的です。

「エージェントがミスをするのを見つけたら、そのたびに時間をかけて、エージェントが二度とそのミスをしないような解決策をエンジニアリングする。」
（同記事、原文を確認）

その後、2026年2月11日に OpenAI が Ryan Lopopolo 氏による記事を公開し、harness engineering を「手で書いたコード0行で本番アプリを出荷した経験」に基づいて定式化したとされます。タグラインは "Humans steer. Agents execute."（人間が舵を取り、エージェントが実行する）。

ただし——ここは正直に。OpenAIの公式記事（openai.com/index/harness-engineering/）は、私が本稿執筆時にアクセスしたところ HTTP 403 で本文を直接取得できませんでした。だから日付・著者・タグライン・「0行」クレーム、そして "Humans steer. Agents execute." という一句は、すべて 二次情報（augmentcode / latent.space / zenml の一致）に基づく ものです。本記事でこのタグラインを再掲する箇所には、毎回「（二次情報）」と付けます。「100万行・1500 PR・1日10億トークン」といった実験規模の数字に至っては、二次情報のみで一次未確認なので、本文の論証材料には使わず、ここで「〜と報じられている」と触れるに留めます。

1-2. Karpathy 氏の "vibe coding" と混同しないために

時系列の整理をしておきます。Andrej Karpathy 氏（OpenAI 共同創業者、Tesla 元AI責任者）が2025年2月2日のツイートで広めた "vibe coding" という言葉があります（原ツイート、URL・日付確認済み）。「AIに任せて、雰囲気でコードを書く」スタイルです。

これは harness engineering（2026-02ごろ業界用語化）より 先行 します。両者は別系統の概念です。後半で私自身の言い回しが出てきますが、それと "vibe coding" の関係は、本記事を通じて慎重に区別します（理由は1-4で）。

1-3. RAPTOR — harness の「実物」がここにある

抽象論はここまで。実物を見せます。

私は RAPTOR というセキュリティ研究フレームワークをローカルで動かしています。これは gadievron/raptor（MITライセンス。作者は Gadi Evron 氏、Daniel Cuthbert 氏、Thomas Dullien 氏〔別名 Halvar Flake〕、Michael Bargury 氏、John Cartwright 氏）からの fork です（upstream リポジトリ、LICENSE と README L23-24 で著者名を確認）。

RAPTOR の正式名は Recursive Autonomous Penetration Testing and Observation Robot。Semgrep（パターンマッチ型の静的解析ツール）/ CodeQL（コードをデータベース化して問い合わせるデータフロー型の静的解析ツール）による解析、バイナリ解析、LLMによる脆弱性検証、エクスプロイト生成、パッチ生成を1つのワークフローに連結する、自律セキュリティ研究フレームワークです。

そして、ここが harness engineering の定義に 後から重ねると素直に対応づけられます。先に断っておくと、RAPTOR の2層構造は、設計者が「harness engineering」という業界用語を意識して書いたものではありません。こちらが事後的に重ねた解釈です（つまり観察者効果込み）。それでも対応は驚くほど自然です。RAPTOR の README は、自身を「2層アーキテクチャ」と明言しています。

「RAPTOR is two layers.（RAPTOR は2つの層からなる）」

Python 実行層（raptor.py, packages/, core/, engine/）は重い処理を担う。Semgrep と CodeQL を走らせ、サブプロセスを管理し、SARIF（静的解析結果を表す標準JSONフォーマット）をパースし、findings を重複排除し、LLM API 呼び出しを差配し、コストを追跡し、出力ファイルを書く。「It does not make decisions. It executes.（決定はしない。実行するだけだ）」

Claude Code 決定層（.claude/, tiers/, CLAUDE.md）が判断する。どの findings を優先するか、結果をどう解釈するか、攻撃シナリオは何か、そのエクスプロイトは現実的か。「makes the calls（判断を下す）」

（upstream README "Architecture" 節、L236-250、本文確認済み）

これを harness engineering の業界定義に重ねると、こう対応します。ハーネス（＝Python実行層）がスキーマ検証・権限・実行・結果注入を担い、LLM（＝Claude Code決定層）は判断に専念する。

設計原則は、リポジトリの CLAUDE.md がさらに端的に規定しています。

「Python orchestrates everything.（Pythonが全てをオーケストレーションする）」
「Never circumvent Python execution flow.（Python実行フローを迂回するな）」

加えて「リモート OLLAMA サーバの場所を漏らすな」「sys.path に RAPTOR_DIR 以外を追加するな（未設定なら KeyError で即停止＝fail-fast、フォールバックなし）」といった、安全側に倒す規律が強制されています。

丸眼鏡の年配男性が険しい顔で「こやつ…さっきまで馬鹿丸出しだったのに…打って変わって賢い風の持論を展開しおる…!!」と内心で訝しむコマ

🗒️ 「こやつ…さっきまで馬鹿丸出しだったのに…／打って変わって賢い風の持論を展開しおる…！！」— ハーネス（器）を1枚かぶせた途端、同じモデルが急に"賢そう"に振る舞い始める。あの手品めいた瞬間のことです。（© Forbidden shibukawa / SHUEISHA・『スナックバス江』）

かみくだき：fail-closed（フェイルクローズド）とは

fail-closed は、「迷ったら通さない」という設計方針です。反対語は fail-open（迷ったら通す）。

たとえば、改札機が壊れたとき。

  • fail-open：壊れたら開きっぱなし（人は通れるが、不正も通る）。
  • fail-closed：壊れたら閉じっぱなし（誰も通れないが、不正も通れない）。

このたとえがどこで壊れるかも添えます。改札なら「通れない人」の不便は一時的ですが、AIエージェントの fail-closed は「安全だが、ときに正当な操作まで止めてしまう」コストを伴います。そのバランスを誰が取るのか——後述の「人間確認（CONFIRM）」が、その緩衝材になります。

セキュリティの世界では、原則 fail-closed です。RAPTOR には、これが複数の場所で実装されています。

  1. untrusted（信頼できない）リポジトリをスキャンするとき、RaptorConfig.get_safe_env() が TERMINAL / EDITOR / VISUAL / BROWSER / PAGER といった「シェルが評価しかねない環境変数」を剥ぎ取り、ファイルパスはシェル文字列に埋め込まずリスト引数で渡します（core/config.py の get_safe_env、CLAUDE.md の "SECURITY: UNTRUSTED REPOS" 節で確認）。
  2. /validate（脆弱性検証）の各段の出力は JSON スキーマ検証を通り、不正なら exit 1 で止まります（libexec/raptor-validate-schema）。

さらに RAPTOR には governance（ガバナンス）パッケージがあり、@govern デコレータが実コードで実装されています（packages/governance/policy.py）。GovernancePolicy が「許可ツール / 禁止ツール / 禁止パターン / リクエストあたり最大呼び出し数 / 人間承認の要否」を宣言的に持ち、check_tool は——

  • 禁止リストに当たれば DENY（拒否）
  • 人間承認が必要なら REVIEW（保留）
  • 許可リストにすら無ければ DENY（＝知らないものは通さない）

を返します。これは紛れもなく fail-closed です。複数ポリシーを合成するときは "most-restrictive-wins"（最も厳しい方が勝つ） で合成し、DENY/REVIEW のときは PermissionError を投げて実行を止めます。

1-4. ここから"もう1つの軸" — モデル中心の図に足したいもの

ここまでは業界の harness engineering と、その実物（RAPTOR）の話でした。ここから、私自身の軸を重ねます。

業界の定義は "Humans steer. Agents execute."（人間が舵を取り、エージェントが実行する／二次情報） でした。私はこれに全面的に賛成です。むしろ、これは 既に人間中心の先例 です。Hashimoto 氏も OpenAI も、人間が舵を取ることを明言している。だから私は「業界は人間の役割を描いていない」とは言いません。それは網羅調査なき誇張です。

正確に言うと、こうです。業界の解説記事は「ハーネス＝モデルを取り囲む技術的な器」というモデル中心の図が多い。 「人間が舵を取る」という方向は示されても、その人間が 具体的に何をして、AIをどう"育てる"のか の粒度までは、あまり踏み込まれていない。私が足したいのは、その粒度です。

harness は「器」であると同時に、「人間が手綱を握り続ける場所」であり、「AIを部下のように育てる場所」でもある。

私はこれを、自分の中で ハーネス型バイブコーディング と呼んでいます。2026年5月に、自分の作業スタイルを言語化したときに出てきた、業界用語の 補助線としての言い回し です。

ここで作法を1つ厳守します。「私が先に命名した」「世界初だ」とは言いません。 理由は2つ。

  1. harness engineering という業界用語（2026-02ごろ、Hashimoto 氏の一次記事で日付確認済み）は、私のこの言い回し（2026-05）より 先行 しています。
  2. そもそも Hashimoto 氏自身が「広く受け入れられた用語があるか分からない」と言っているくらいで、誰が「最初」かを断定できる状況ではありません。

だから本記事での私の立場は、「Karpathy 氏の "vibe coding"（2025-02、AIに全任せ）とは明確に区別される、人間中心の運用スタイルを、私はこう呼んでいる」 です。"vibe coding" が「AIに任せて雰囲気で」だとすれば、私のスタイルは「ハーネスを能動的に握り続け、AIを部下として育てながら使う」です。

以降は、造語そのものを前面化するのをやめ、機能（手綱を握る人間／部下育成） で語ります。

ハーネス型バイブコーディングの3分解

要素 中身
harness Claude Code / Codex / Cursor / Aider 等の、エージェント駆動の開発環境
vibe ユーザー側のイメージ・直感・全体感覚（＝高次元の方向性）
coding AIが細部を埋める実装作業

ユーザーは、この3つを harness 経由で接続する。"vibe"（直感）は捨てるものではなく、最も価値ある入力として扱います。

ユーザー側に必要な3つの能力

この軸の中核は、「人間がただ眺めているだけではダメ」という点です。ユーザー側に3つの能力が要ると考えています。

能力 役割 私の場合の根拠
発想力 高次元の方向性提示・異分野連想・新規要件の発見 「キン肉星＋R.O.D＋リィンカーネーション＋ROS PBT」の4連想で派生集団進化の設計が一瞬で固まった、あの瞬発力
経験則 設計判断のショートカット・似た失敗の先読み・不要な探索の打ち切り 30年のエンジニア経験＋精密計測＋産業IoT＋DX経験
アルゴリズム理解 AIが出した実装の妥当性検証・計算量の見積り・ホットパスの特定・ベンチの honest disclosure 「単発で約0.8倍、バッチで約12.7倍」という差を一瞬で評価できる地頭

3つ目の「アルゴリズム理解」が特に大事です。よく言われることですが、AIは流暢に間違えます。 流暢な間違いを見抜くには、こちらに計算量を見積もる目が要る。これは新規の洞察ではありません。私が言いたいのは一般論の再確認ではなく、運用上の具体です——たとえば上の「単発0.8倍／バッチ12.7倍」という1か月前の自前計測。AIは「バッチで12倍速い」とだけ報告しがちですが、単発では遅くなっているという不都合な内訳を見落とさないために、計算量の目が要る、という話です。

そして「AI成長マネジメント」— 部下育成と同じ"構造"

ここが私の軸でいちばん言いたいことです。AIを使うことは、部下を育てることに驚くほど似ている。 対応表を作ると、こうなります。

部下育成 AI育成（実装上の受け皿）
目標を共有する CLAUDE.md / memory / requirements docs で意図と制約を毎セッション展開
委任範囲を決める 自律範囲ルール（max-plan-autonomy / session-marathon）で明示
進捗を確認する SESSION_SUMMARY / NEXT_SESSION / git log を毎ターン更新
失敗を許す 雑談メモ・honest disclosure・負の例（negative example）も消さずに残す
成長を測る ベンチ / テスト通過数 / 統計駆動
個性を尊重する persona / 思考因子 / Novelty Lane で独自進化を保護
引退・世代交代 旧 commit / 旧 memory を消さず archive
信頼関係を作る Approval Bus ＋ Ed25519 audit chain（電子署名で改ざん不能にした承認ログ）でユーザーに監査権を渡す

ここで重要な留保を1つ。この対応表は「比喩がよく効く」ことを示すものであって、それ自体は「人間がAIより優位だ」の証明ではありません。 人間マネジメントの本がそのままAIチームに読めることは、メタファの有効性であって、優位性の根拠ではない。優位性の論拠は、本章ではなく第3章末の3点（並列／長射程／危険予知）に一本化します。ここでは「育てる構造が転用できる」とだけ主張します。

穏やかに微笑む年配の男性が「誰にしつけが必要かって話になると…」「人類じゃねぇか?」「ラスボス?」と語るコマ

🗒️ 「誰にしつけが必要かって話になると…／人類じゃねぇか？／ラスボス？」— 部下育成の比喩をひっくり返すと、こうなります。雑な指示・後出しの仕様変更・曖昧な合格ライン——しつけが要るのは、案外こちら側かもしれません。（© Forbidden shibukawa / SHUEISHA・『スナックバス江』）

なぜ転用が効くのか。理由は4つに整理できます。

  1. AIは文脈ロスが速い → 確認待ちのコストが、多少ズレても進む価値を上回る。
  2. AIはやり直しが安い → 自律で間違えても即修正できる。再構築コストが低い。
  3. AIは休まない → 人間の確認待ちが最大のボトルネック。
  4. AIは説明できる → なぜそう判断したかを後から audit log で追える。

なお、この発想には系譜があります。Marcus Buckingham 氏 & Curt Coffman 氏の名著 First, Break All the Rules（原著1999、米ギャラップ社の大規模調査を基にしたマネジメント書）が説く「個性を生かすマネジメント」を、人間ではなく AIチーム に転写したものです（邦題・刊行年・4原則の要約はメモ記載値に基づくので、原著該当箇所での再確認が望ましく、ここはヘッジします）。彼らの4原則——(1) 才能で選べ (2) 正しい結果を定義せよ (3) 強みに集中させよ (4) 適所に配置せよ——は、ほぼそのまま「人間→AIチーム」のマネジメントに転用できる、と私は感じています。

人間マネージャーが人間チームを率いる本が、ほとんどそのまま、人間がAIチームを率いる本として読める。

（もう1つ、キヤノンの「三自の精神（自発・自治・自立）」をAIに当てはめる整理も手元にありますが、これは出典が社内に語られる訓えで一次確認が取れていないため、本記事では脚注的に名前を挙げるに留め、論証の柱には First, Break All the Rules 側を据えます。）

この章の honest disclosure（圧縮版）

  • 「ハーネス型バイブコーディング」が私の造語かは私の推定で、外部検索で確定させていません。だから「命名した／世界初」とは書かず「私はこう呼んでいる」に留めています。
  • 「約0.8倍→約12.7倍」などの数値は約1か月前の時点記録で、最新コードでの再検証はしていません。数字そのものより「こういう不都合な内訳を見抜く目が要る」という論点として読んでください。

アンチパターン（やってはいけないこと）

部下育成と同じで、「育てる」には禁じ手があります。

  • ユーザーの直感を「データがない」で却下する。
  • 経験則を「まず先行研究を見ましょう」で置き換える。
  • アルゴリズムの議論を抽象論に逃がす。
  • AIを「ツール」扱いして育成せず、毎回ゼロからやらせる。
  • 厳しすぎ／甘すぎでバランスを崩す。
  • harness そのもの（CLAUDE.md / hook / settings）を勝手に変える。
  • ユーザーが手綱を握れないように、進捗を隠す（不透明な進捗、曖昧なコミットメッセージ）。

最後の2つは、AI側にも振る舞いの規律として課しています。完了した変更はファイルパスと内容を1行で示し、プロセスを観測可能に保つ。 手綱を握る人間に、いつでも全体が見えるようにしておく。これが「手綱を握れる harness」の必要条件です。

🗨️ 「IQに差がある者とは会話が噛み合わない」 — スナックバス江／フォビドゥン澁川（アル）

（閑話休題）人間とAIの「会話の噛み合わなさ」も、結局はここに尽きます。賢いAIに雑に頼むと、賢いがゆえに勝手に補完して、意図とズレた場所へ全力で走っていく。だから「手綱」と「ループの判断」が要る——この箸休めのあと、いよいよ「輪」の話に移ります。

第1章は「なぜ（哲学）」でした。harness は技術的な器であると同時に、人間が手綱を握り、AIを部下として育てる場所だ——というモデル中心の図への補助線を置きました。次の第2章は「どう（制御）」に移ります。

第2章【輪 = loop】ループエンジニアリングと、自作ハーネス llloop

2-1. loop engineering をもう一段、深く

第0章で「automation は手順、loop は判断」と定義しました（卵とレシピの話）。もう一歩踏み込むと、loop engineering はこう言えます。

ループを「設計し、回し、戦略を差し替えて比較・改良する」工学。

ポイントは「戦略を差し替えて比較できる」ことです。固定の1ループではなく、ループの中身（戦略）を react / reflexion / plan_execute_verify のように入れ替えて、「同じタスクでどの戦略が速く・安全に収束するか」を実験する。これが automation（固定レシピ）との決定的な違いです。

かみくだき：戦略の名前たち

ループの「中身」にあたる代表的な戦略を、ざっくり訳しておきます。

  • ReAct（リアクト） … 「考える（Reason）」と「動く（Act）」を交互に繰り返す。
  • Reflexion（リフレクション） … 失敗したら自分で反省文を書いて、次の試行に活かす。
  • Plan-and-Execute（計画して実行） … まず計画を立て、それから順に実行する。
  • Self-Refine（自己改善） … 自分の出力を自分で添削して直す。

これらは「思考の回し方の流派」です。同じゴールでも、流派によって到達の速さも、踏み外しやすさも変わる。だから「比較する枠組み」が要るのです。

2-2. loop engineering にもセキュリティの顔がある

loop engineering は、生産性の話だけではありません。セキュリティのパラダイム転換でもあります。

Filip Verloy 氏が2026年6月の Medium 記事 From Prompt Engineering to Loop Engineering: Why the Agent Era Demands a New Security Paradigm で、鋭い警告をしています。

「ネイティブなエージェント制御層なしに自律ループを解き放つと、生産性をスケールするのではなく、マシン速度でリスクをスケールする（scaling risk at machine speed）。」
（Medium記事、本文確認済み）

ループは速い。だからこそ、止め方を間違えると、間違いも全力で量産される。彼の処方箋は、正規表現やACLのような静的制御では足りず、エージェントの行為の意味を実時間で理解して制御する Semantic Governance（意味論的ガバナンス） が要る、というものです（言い換えではなく原記事の主張に沿って要約）。

この「マシン速度でリスクをスケールする」という一文が、次の自作ハーネスの設計動機そのものです。

2-3. llloop — 自作のループハーネス

私は llloop（ローカルの独立プロジェクト、v0.1.0a0、Apache-2.0）という、自律ループを設計・実行・実験するための独立ハーネスを自作しています。2026年6月11日発足の Python プロジェクトです。

最初に honest disclosure を置きます。llloop は alpha 段階（v0.1.0a0、スケルトン）です。 GitHub への公開はまだしていないので、本文に公開リポジトリの URL は貼れません（公開済みの RAPTOR 側リンクで補います）。実証タスクも今は green-keeper 中心で、production 品質ではありません。盛らずに書きます。

その上で、設計の骨格はこうです。

骨格：MAPE-K 制御ループ

llloop の背骨は MAPE-K です。これは自律コンピューティング（autonomic computing）の古典的な制御ループで、Monitor（監視）→ Analyze（分析）→ Plan（計画）→ Execute（実行）、それらが共有する Knowledge（知識 K） からなります。設計コードには Kephart & Chess の2003年の autonomic computing 論文が引用されています。

実装は MapeKRunner クラスで、1周回が——

Monitor → Analyze →（ゴールを満たせば終了）→ Plan → 安全判定 → Execute → 記録 → breaker/budget 判定

の順に閉ループします。内ループには plan-execute-verify と Reflexion を採用し、戦略は差し替え可能です。

かみくだき：MAPE-K を体温調節にたとえると

MAPE-K は、人間の体温調節に似ています。

  • Monitor（監視）：体温計が「38度ある」と気づく。
  • Analyze（分析）：「平熱より高い、これは発熱だ」と判断する。
  • Plan（計画）：「汗をかいて熱を逃がそう」と決める。
  • Execute（実行）：実際に汗をかく。
  • Knowledge（知識）：「平熱は36.5度」という基準を全段で共有している。

automation（レシピ）との違いは明白です。レシピなら「夏になったら汗をかく」と日付で決め打ちしますが、MAPE-K は 今の体温を測って判断する。これが「中で判断するループ」です。

2-4. ★主役登場：fail-closed 安全層（safety.py）

ここが llloop でいちばん語りたい部分です。loop は速い。速いものには、迂回できないブレーキが要る。第2-1で「判断点を持つことと判断の質を保証することは別問題」と書きました。その「質を保証する」担当が、この安全層です。

llloop の安全層 safety.py の SafetyPolicy.classify は、各アクションを ALLOW（許可）/ CONFIRM（人間確認）/ FORBID（禁止） の3段で判定します。判定順は——

  1. FORBID を最優先 … rm -rf /、curl | sh（ネット越しの内容をそのままシェルに流す）、--no-verify（フック迂回）、fork bomb などは無条件禁止。
  2. 危険コマンドは CONFIRM … 削除、force-push、submodule 改変、DB drop は人間確認必須。
  3. 未知の種別も CONFIRM … 知らないアクション種別は、許可リストに無いので 安全側（確認）に倒れる。
  4. 残りだけ ALLOW … read / scan / test / lint / typecheck / build / commit / push は自律許可。

第0章で出てきた「fail-closed（迷ったら通さない）」が、まさにこの順序で実装されています。「知らないものは ALLOW にしない。CONFIRM か FORBID に倒す。」——これが「automation と loop の違い」を安全の側から体現しています。レシピなら未知の手順を素通りしますが、判断するループは「これは知らない。だから止めて聞く」と振る舞う。

そして暴走防止の3点セット。

  • CircuitBreaker（サーキットブレーカー＝電気のブレーカー） … 連続失敗 N 回（既定3）、または進捗スコアが一定周回（既定4周）改善しない発散・停滞を検知したら trip（遮断）。家のブレーカーと同じで、「同じ失敗を繰り返す」「進捗が伸びない」という空回りを検知し、APIコストだけ燃やす事故を構造で防ぎます。
  • Budget（予算） … 反復回数（既定20）/ 時間（既定1800秒）/ アクション数（既定200）の ハードキャップ。
  • 認証要求検知 … 出力に /login、401、session expired などの兆候を見つけたら 即ループ停止。

金髪の明美が真顔で「理解できないという事は敵かしら…?」と言い、横から「怖い考え方してるよ…!」とツッコまれるコマ

🗒️ 「理解できないという事は敵かしら…？／怖い考え方してるよ…！」— fail-closed に人格を持たせると、だいたいこうなります。知らない種別は ALLOW にしない。怖い考え方ですが、ブレーキとしては正しい。（© Forbidden shibukawa / SHUEISHA・『スナックバス江』）

2-5. LLM を使っても、現状の実装では安全層を迂回できない

見出しを正確にしました。「現状の実装では」 という限定が本質的だからです（理由は本節末で開示します）。

「LLMで動かすなら、結局LLMが暴走するのでは?」——もっともな疑問です。llloop の答えは、構造で迂回不可にすること。

LLMStrategy は、LLMに「次のアクションをJSONで1つだけ」提案させます。しかし——

  • LLMの出力は untrusted（信頼できない） として扱い、parse_action で厳格にパースする（最初の {…} ブロックのみ採用、kind は許可リスト検証、解析不能なら破棄）。
  • 実際のコマンドの危険判定は、LLMではなく runner 側の SafetyPolicy が下す。
  • LLMが不在（codex CLI が PATH にない）なら、決定論的なフォールバック戦略へ縮退する（これも fail-closed）。

つまり設計核心は——

LLM は「提案」しかできない。最終ゲートは SafetyPolicy。現状の経路では、LLM は安全層を迂回できない。

実際、テストでは「LLMが危険な削除アクションを提案しても、runner が SAFETY_BLOCKED で止める」ことを実証しています。これは第1章の RAPTOR の思想——「Python が判断の前段を握り、LLM は判断に専念する」——と、まったく同じ構図です。

honest disclosure（なぜ「現状の実装では」と限定するか）

「LLMが安全層を迂回できない」は、コード上の経路（LLMStrategy → parse_action → runner.SafetyPolicy）として構造的に保証されています。ただしこれは「llloop の Executor 経由でしかコマンドを実行しない」前提に依存する、条件付きの命題です。codex exec 自体は -s read-only のサンドボックスで副作用を起こさない設計ですが、もし将来 Executor の外でLLMに直接シェルを叩かせる経路を足せば、保証は崩れます。現状の実装にその経路はありません——だから見出しを無条件の「迂回できない」ではなく「現状の実装では迂回できない」にしてあります。

🗨️ 「成果は? 嘘ついていい? 確認を取るなんて逆に正直だ…」 — スナックバス江／フォビドゥン澁川（アル）

（閑話休題）「確認を取る」のは弱さではなく正直さです。llloop の CONFIRM も同じ——迷ったら止めて聞く。手綱を握る人間に判断を返す、これが「迂回できないブレーキ」の作法です。

2-6. 起動と実証タスク green-keeper

llloop の起動コマンドは lll（console script ＝ パッケージをインストールすると PATH に入る起動コマンド）。引数なしで起動すると、ccr 風の対話メニュー（プロジェクト選択＋ next_plan / last_outcome の引き継ぎ表示＋既定30秒でアクティブプロジェクト自動継続）が出て、初回実証タスク green-keeper を実行します。

green-keeper は GitOps reconciliation（reconciliation ＝「あるべき姿」と「今の姿」を突き合わせて差を埋める整合化） 風のループです。庭師が「全部の草木が元気な状態」を desired として、枯れかけ（drift）を見つけたら水をやる、というイメージ。

green-keeper の場合：

  • desired … 全チェック（pytest / ruff / mypy）が緑。
  • actual … 実行結果。
  • drift … 失敗しているチェックを「症状（Symptom）」として捉える。
  • 修復 … ruff --fix のような安全な自己修復を提案する。

push まで自律可能ですが、既定の修復に破壊操作は含めません（ここでも fail-closed）。

テストは stdlib のみ依存、mypy strict / ruff green で、現時点 90 件（test_safety / test_runner / test_strategies / test_llm / test_stdin_isolation / test_console_e2e / test_interactive_menu 等）。これは「テスト関数を数えた」値です。

honest disclosure（テスト緑について）

「テスト90件が緑」は、テスト関数の数とコードの存在から裏付けたもので、本稿執筆中に pytest を実際に走らせて緑を再確認したわけではありません。確度は「直近コミット時点で緑だった」レベル。「最新で緑」と言い切るには再実行が要る、という温度感を保ちます。

2-7. 「検証可能なゴール」を持つループ — /goal という公式実装

ループハーネスができると、次に湧くのが「それをどこから駆動するか」という問いです。第0章で「ループにはトリガーと検証可能なゴールが要る」と書きました。そのトリガー側を外部化する話は別記事に譲り（スマホからSSHでWindows PCのClaude Codeを操作する方法——ハーネスを外部から駆動する入口の話として読めます）、ここでは「検証可能なゴール」側に絞ります。

Claude Code 公式の /goal コマンドが、これの教科書的な実装です。完了条件（condition）を設定すると、各ターン終了後に「小さく速いモデル（既定で Haiku）」が条件充足を判定し、未達なら自動で次ターンを開始、達成で自動クリアします（公式 docs で「v2.1.139 or later」「each turn, a small fast model checks whether the condition holds」「defaults to Haiku」を確認）。まさに「検証可能なゴールを持つループ」です。条件は「or stop after 20 turns」のようにターン上限も書けます——暴走防止のキャップは、ここでも基本作法なのです。

（v2.1.139 のリリース日「2026年5月12日」は二次情報のみで、公式 docs にはバージョン要件はあっても日付の明記がないので、日付はヘッジします。）

🗨️ 「謎のグラフのおかげで悲壮感が薄い」 — スナックバス江／フォビドゥン澁川（アル）

（閑話休題）ベンチマークの数字も、雰囲気で「謎のグラフ」を出せば悲壮感は薄まります。でも、本記事の作法は逆。謎のグラフこそ内訳を疑う。 次の節で、まさにその実演をします。

第2章は「どう（制御）」でした。MAPE-K で回し、fail-closed の安全層で迂回不可のブレーキを掛け、戦略を差し替えて比較する——これが loop engineering の試作です。ここで、冒頭で予告した「捨てた数字」の検証を、独立した節として置きます。

★ honest disclosure：私が「使うのをやめた」数字の話

冒頭で触れた、捨てた数字の正体を開示します。よく引用される、こういう主張でした。

「ある2026年の論文（arXiv 2605.18747）が、モデルを固定したままツールハーネスだけを変えて、最大10×の改善を示した」

ハーネスの威力を語るときの、ちょうどいい"つかみ"です。これを一次情報で確かめました。結論——この主張は、そのままでは使えません。

  • arXiv 2605.18747 は実在します。タイトルは Code as Agent Harness、2026年5月18日投稿、第一著者 Xuying Ning 氏ほか 計42名のサーベイ論文 です（arXiv:2605.18747、本稿執筆時に本文を再確認）。
  • しかし、その著者一覧に「Bölük / Boluk」という名前は 存在しません。
  • 抄録に「10x」などの具体的な数値クレームも ありません。

つまり「Bölük が 2605.18747 で 10× を示した」という3点セット（著者名・数字・論文番号）の結びつきは、出所不明の混同とみられます。私は、この数字を記事の"つかみ"に使いたい誘惑がありました。キャッチーですから。でも、一次にあたったら根拠がなかった。だから捨てます。

ではハーネスに本当に威力がないのか? そうではありません。「モデルを固定し、周辺ランタイム（ハーネス）だけを変えると大きな性能差が出る」こと自体は、別ソースで裏付けがあります。ただし以下の数値は、私が辿れたのは二次情報の引用までで、一次の計測元・計測条件まで遡れていません。だから全て「〜による報告（二次引用）」として扱います。

  • LangChain が、コーディングエージェントを Terminal-Bench 2.0 で 52.8% → 66.5%（同一モデル、ハーネス再構築のみ）に伸ばした、という報告（二次引用・計測条件未確認）。
  • 同一作業で GPT-5.5 とされるモデルが、あるハーネスで約61%、別のハーネスで約87%だった、という比較も流通していますが、モデル名「GPT-5.5」自体が私の知識の範囲外で要検証、かつ数値も二次のみのため、本記事では具体値を論証材料に使いません（「ハーネス差で大きく動く例として語られている」程度に留めます）。
  • 専用ベンチ Harness-Bench（arXiv:2605.27922）は実在。
  • 関連論文 From Model Scaling to System Scaling: Scaling the Harness in Agentic AI（arXiv:2605.26112、第一著者 Shangding Gu 氏、2026-05-25）も実在。ただしこの抄録にも「10×」の数値はなく、著者の所属は abstract ページに記載がないため、よく併記される「UC Berkeley」は 二次情報 として扱います（本稿執筆時に abstract ページを再確認）。

教訓は、冒頭で置いた作法そのものです。

異常にキャッチーな数字を見たら、勝った気になる前に内訳を疑う。引用元の3点セット（誰が・どの論文で・いくつ）が噛み合っているか、一次で確かめる。

ハーネスは強力です。でもその強力さを語るのに、誤った権威付けは要らない。正しい出典の、正しい数字で十分です。

🗨️ 「無知の知」 — スナックバス江／フォビドゥン澁川（アル）

（閑話休題）「自分は知らない、ということを知っている」——これが honest disclosure の精神です。AIは知らないことも流暢に語れてしまう。だから人間の側に「ここは未検証だ」と線を引く目が要る。第1章の「アルゴリズム理解」も、結局はこの無知の知の一形態なのだと思います。

第3章【知 = RAPTOR + RAD + LLM Wiki】ハーネスとループに「知識」を流し込む

第1章で「手綱（harness）」、第2章で「輪（loop）」を見ました。最後は「知（knowledge）」です。ハーネスもループも、良い判断材料がなければ、ただの空回りです。賢く回すには、回す中身——知識——が要る。

私のスタックは、知識を3つの層で持っています。

  1. 自前の研究知識（RAD コーパス） … 約65分野・約4.7万ノートの、ローカルに置いた研究知識。
  2. Wiki的に育つ知識（LLM Wiki パターン） … 生のソースから「概念ページ」を編み上げ、相互リンクで育てる知識キャッシュ。
  3. それを安全に使う security agent（RAPTOR） … 第1章で見た、Python が全制御する決定論オーケストレーション。

3-1. RAD コーパス — 自前の研究図書館

RAD（Research Aggregation Directory、研究集約ディレクトリ） は、ローカルに置いた研究知識の集まりです。RAD_INDEX.md（自動生成）が冒頭で「65 RAD corpora（65個のRADコーパス）」と明記しています。これは rad-research というスキルが grep で横断検索する、内部の知識源です。

規模を 正確に内訳付きで 書きます。ここは数え方で数字が変わるので、丸めません。

  • コーパス数：65分野（実カウント検証済み）。
  • _corpus_v2 内の Markdown ノート：約 47,097 個（.md 実数）。全ファイルだと約 47,130。
  • 別ディレクトリに hacker_corpus（セキュリティ専用：phrack / ghsa / capec / d3fend / oss_security / project_zero / payloads_all_the_things 等）が約 32,503 ファイル。

honest disclosure（「約49k件」という数字の扱い）

世間に出すとき、私はよく「自前の研究知識 約4.9万件（約49k）」と丸めます。この数字の出所は、2026年5月9日の大規模拡張時の集計記録（拡張で 16,377 docs を追加し total 約48,800 に到達）です。

ただし、今回ディスク上で全 documents 数を実カウントし直したわけではありません（コーパス数65と一部コーパスの note 数は実カウント検証済み）。また hacker_corpus は raw（生）集約ファイルで、1ファイルが多数の docs を内包する形なので、「ファイル数」と「内包 docs 数」が一致しません。

だから正直に書くなら——

約65分野・約4.7万ノート（Markdown実数）。別途 hacker_corpus 約3.2万ファイル。丸めて『約49k件規模』と言う場合は『2026年5月拡張時の集計値』という時点付きで。

冒頭で言った「異常に大きい数字は内訳を疑う」を、自分の数字でも淡々と適用しているわけです。

🗨️ 「運…逆に実力を感じる運の言い方」 — スナックバス江／フォビドゥン澁川（アル）

（閑話休題）「49k件」も同じです。大きい数字ほど内訳を疑う。"すごい運"の正体が実力だったりするように、"すごい規模"の正体は『2026年5月集計時点の丸め』だったりする。気持ちよく盛れる数字こそ、一度立ち止まる。

RAD の運用ルール — 蓄積一辺倒にしない

RAD は「集めて終わり」ではありません。3つの運用規律があります。

  1. K² サイジング … コーパスの大きさは「100固定」ではなく、トピックの内部分類数 K に対して 約 K² ノートを目標にする（K≈10 なら約100）。薄すぎる（約40未満）なら K² へ拡張する。
  2. 鮮度 × 価値で剪定 … rad_prune.py が各ノートを「鮮度（収集からの経過時間の指数減衰）× 価値（本文量＋出典の有無）」で採点し、下位を .pruned/ へ退避する。削除は不可逆なので 既定は dry-run（実際には消さず、何が消えるかを予行演習で示すだけ）、実削除は --hard 指定時のみ。これも fail-closed の発想です。
  3. エージェント直書き … 収集は arxiv / scholar-search / fetch / firecrawl / WebSearch を総動員し、結果をディスクに直接書く。これは過去に「巨大な収集結果を main コンテキストへ戻して session limit に達した」教訓を反映した設計です。

本記事の3テーマに直結するコーパスとして、loop_engineering_corpus_v2 が実在します。これは a001..a048（48ノート）＋ b001..b048（48ノート）＝ 計96ノート の file-per-note 構成で、SKILL.md の note_count も96で一致（score 0.982）。

中身は——制御フィードバック（PID / anti-windup〔積分項の暴走を抑える仕組み〕/ state-space〔状態空間表現〕/ Lyapunov〔安定性解析〕/ MPC〔モデル予測制御〕/ MAPE-K / OODA / cybernetics）、自律エージェントループ（ReAct / Reflexion / Plan-and-Execute / Self-Refine / Tree-of-Thoughts 等）、強化学習の各流派（policy-value iteration / PPO / RLHF / RLAIF / Constitutional / RLVR / AlphaZero 等）、運用CI（GitOps reconciliation / watchdog / chaos engineering）——を網羅します。実ノート例：a001_pid_control / a009_ooda_loop_boyd / a013_mape_k_autonomic_loop / b001_mape_k_autonomic_reference_loop。

つまり、第2章の llloop の MAPE-K も safety も green-keeper（GitOps reconciliation）も、このコーパスを設計根拠として実装されているわけです。知識（コーパス）→ ループ（llloop）という流れが、実物で繋がっています。

honest disclosure（「50手法」と「96ノート」の食い違い）

当初メモには loop_engineering = 50手法 とありますが、実体は 96ノート（2シャード） です。これは「当初50手法を調査の起点にし、後に file-per-note で96ノートへ拡張した」という時系列の差です。だから本記事では「約50の手法を起点に96ノートへ拡張」と書きます。「96手法」と盛りません。

さらに、corpus2skill（後述）で生成した階層スキル側（.claude/skills/corpus/loop_engineering/INDEX.md）は「39 documents / 12 clusters」と表示します。これは古いソース版からビルドされた階層で、最新の96ノートを再 corpus2skill していないためです。生コーパス（96）と階層スキル（39）の数を混同しないよう注記しておきます。

3-2. LLM Wiki — 「育つ知識」のパターン

集めた知識は、放っておくと「ただの山」です。検索はできても、繋がって育つことはない。そこで LLM Wiki パターンが効いてきます。

これは Andrej Karpathy 氏の発言として流通しているパターン（メモでは2026-04の Gist 由来。ただし一次 Gist の URL を本稿で確認できていないため、提案者・日付ともにヘッジします）で、知識を3層で持ちます。

  1. 生ソース層（raw、変更不可） … 元の文献・ログ。改変しない。
  2. Wiki層（compiled、LLM が管理する概念ページ） … LLM が要約・相互リンクして編む「概念ページ」。
  3. スキーマ層（schema） … 「どんなページを、どう更新するか」の設計図。

かみくだき：RAG と LLM Wiki の違い

RAG（検索拡張生成） は「質問が来たら、その都度ライブラリへ走って関連本を探す」方式。オンデマンドです。

LLM Wiki は「よく使う知識を、あらかじめ整理してWikiにまとめておき、それを使い回す」コンパイル型。先にまとめておく方式です。

この2つは対立ではなく 補完 です。理想形は「整理された Wiki を、RAG で検索する」——よく整頓された図書館（Wiki）を、司書（RAG）が素早く案内する、というイメージです。

私はこの LLM Wiki パターンを、2つの実体に対応づけています（いずれも設計段階で、実装は後続フェーズであることを明示します。以下は「私のマッピング（主観）」であって、実装済みの同型性ではありません）。

  • llive（self-evolving modular memory LLM フレームワーク）の Phase 2-4 要件 LLW-01〜08。たとえば LLW-01 ConceptPage、LLW-02 Wiki Compiler、LLW-04 矛盾検出、LLW-08 RAG×Wiki 二層運用。
  • RAPTOR の corpus2skill を、継続更新型の ingest ループへ拡張する v2 構想。

llive の4層メモリ設計は、私の対応づけでは Karpathy 氏のパターンと構造的にマップできます（あくまで設計意図としての対応で、実装はこれから）。semantic memory ≈ Wiki層、episodic memory ≈ 生ソース層、Hippocampal Consolidation Scheduler ≈ Wiki Compiler、Contradiction Detector ≈ 矛盾指摘、structural memory（グラフ）≈ ページ間リンク、Provenance ≈ ソース追跡。

★ LLM Wiki 最大の落とし穴：思考の循環

ここは honest disclosure と表裏一体の、重要な設計上の警告です。LLM Wiki の最大の落とし穴は 「思考の循環（thought circulation）」 です。

LLM が、自分で書いた Wiki ページを根拠にして、新しいページを生成する。すると、最初の小さなハルシネーション（もっともらしい誤り）が、「合意」として固定化されていく。

自分の書いた間違いを、自分で引用して、それを正しいことにしてしまう。一人で噂を流して、その噂を「みんなが言っている」と信じ込むようなものです。loop は速いので（第2章の Verloy 氏の警告を思い出してください）、この循環もマシン速度で固定化されかねません。

llive はこれに対し Anti-Circulation Safeguards（反循環の安全装置、LLW-AC-01〜08） を設計しています（設計段階）。

  • raw events を authoritative（正本）とし、既存の要約は working draft（作業中の草稿）に過ぎないと扱う。
  • 1サイクル内での連鎖統合を禁止（自分の出力を即座に次の根拠にしない）。
  • drift detection を周期実行（ズレの定期点検）。
  • diversity preservation（少数派の証拠を保護し、多数派に塗り潰させない）。
  • 外部 ground-truth anchor（CAD / DOI / 形式検証の hash など、外部の動かない事実）を必須化する。

最後の「外部アンカー必須」は、本記事全体を貫く姿勢——一次情報主義——そのものです。AIが自分の中だけで完結させず、必ず外の動かない事実に錨を下ろす。

🗨️ 「半信×半疑」 — スナックバス江／フォビドゥン澁川（アル）

（閑話休題）思考の循環への特効薬が、この半信半疑です。自分が書いた要約すら「working draft」と疑い、外の動かない事実（DOI / hash / CAD）に錨を下ろす。AIが自分の流した噂を「みんなが言っている」と信じ込まないための、健全な疑い。

なお、FullSense（後述）は llmesh / llive / llove の3製品で構成されます。LLM Wiki の役割を製品にマップするなら llive が「Wiki 編集者」、llove が「Wiki の UI」、llmesh が「生ソースを運ぶ Bus」 に当たります（RAG は製品ではなく検索の手法なので、製品の列には入れず、3製品の上で使う道具と位置づけます）。

3-3. RAPTOR が「知識を安全に使う」入口を兼ねる

知識（RAD / LLM Wiki）を、誰が安全に使うのか。それが第1章の RAPTOR です。RAPTOR では、/sourcehunt（ファイル単位の脆弱性ハント）を走らせると、corpus が存在すれば knowledge base が自動ロードされ、get_hints(tags) で分析コンテキストに根拠付きで注入されます。

そして RAPTOR は、知識の使い方そのものに証拠の段階を持ち込んでいます。/sourcehunt の 証拠ラダー（evidence ladder） は6段です。

suspicion（疑い）
  → static_corroboration（静的な裏付け）
    → crash_reproduced（クラッシュ再現）
      → root_cause_explained（根本原因の説明）
        → exploit_demonstrated（エクスプロイト実証）
          → patch_validated（パッチ検証済み）

ASan / UBSan（実行時にメモリ異常や未定義動作を検出するサニタイザ）がクラッシュを再現すると、証拠が「静的な裏付け」から「クラッシュ再現」へ格上げされ、これが PoC（Proof of Concept ＝ 脆弱性を実際に踏める実証コード）生成のゲートになります。つまり「疑い」を「実証」と同列に扱わない。証拠の重みを段階で表現する。

これは出力スタイルにも制度化されています。RAPTOR のステータスは、JSON では snake_case（exploitable / confirmed / ruled_out / disproven）、人間可読では Title Case、ALL_CAPS は禁止。さらに 🔴/🟢 の赤緑インジケータは禁止です。理由が秀逸で——「防御側に悪い ≠ 研究者に悪い」、つまり良し悪しは視点に依存するから、安易に赤緑で断じない。findings を誇張せず、証拠レベルで段階表現する。これは honest disclosure を設計レベルで強制する仕組みです。

3-4. corpus-first advantage — 一人開発でも「多視点」になりうる

最後に、なぜこの「知識スタック」が私の独自軸（第1章）と噛み合うのか。

corpus-first（コーパス先行）戦略という気づきがあります。RAD コーパスを先に育てておくと、一人開発でも、ユーザーが意識しない観点——Six Hats（6つの帽子）、TRIZ（発明原理）、KJ法、MindMap、異分野類比——が、AIの思考フローに補完されうるのです。

ここは「されうる」と条件付きで書きます。コーパス参照は万能ではありません。関連性フィルタが効かないと、無関係・古い知識が混ざって逆にノイズになる。実際、3-1で書いた「鮮度×価値の剪定」は、まさにこのノイズ混入を抑えるための装置です。だから正確には「関連性フィルタが効いている前提で、多視点が補完されうる」が正しい温度感です。

具体例を1つ。第2章の llloop の安全層を設計するとき、私は「fail-closed を3段（ALLOW/CONFIRM/FORBID）にする」という発想を、loop_engineering_corpus_v2 の制御理論ノート群（anti-windup や circuit breaker パターン）と、RAPTOR の governance（DENY/REVIEW/許可リスト外DENY）の両方から引いてきました。一人で設計していても、コーパスが「制御工学の視点」と「セキュリティの視点」を背後で重ねてくれた——これが corpus-first の効き方の一例です。

これは「AIを使う（答えを聞く）」と「AIと一緒に作る（背景でコーパスを参照し、多視点を補完しながら、設計判断は人間が握る）」の違いに対応します。第1章で「ユーザー側に発想力・経験則・アルゴリズム理解の3能力が要る」と書きました。corpus-first は、その3能力を AI側の知識基盤で増幅しうる仕掛けです（ノイズ管理が前提、という留保つきで）。

金髪の明美が「整理整頓した後って何処に何があるか分からなくならない?」と首をかしげ、「出来てないんだよそれは…!」とツッコまれるコマ

🗒️ 「整理整頓した後って何処に何があるか分からなくならない？／出来てないんだよそれは…！」— 4.7万ノートも、必要なときに引けなければただの山です。「関連性フィルタが効いている前提で」という留保は、つまりこういうこと。（© Forbidden shibukawa / SHUEISHA・『スナックバス江』）

人間が手綱を握り（A）、ループが安全に回り（B）、そのループに多視点の知識が流れ込む（C）——ここで3つが1本に繋がります。

第3章は「何を（実装と知識）」でした。RAD で知識を集め、LLM Wiki で育て（循環の落とし穴に安全装置を付け）、RAPTOR が証拠の段階を守って安全に使う。いよいよ統合です。

統合章：A（なぜ）→ B（どう）→ C（何を）が1つの世界観になる

ここまでの3章を、1枚に畳みます。

テーマ 問い 実物 "もう1つの軸"
A harness engineering なぜ（哲学） RAPTOR の2層分離 人間が手綱を握り、AIを部下として育てる
B loop engineering どう（制御） llloop（MAPE-K＋fail-closed、alpha） 安全層は現状の経路では迂回不可・戦略を差し替えて比較
C RAD + LLM Wiki 何を（知識） 約4.7万ノート（※2026年5月集計時点）＋証拠ラダー corpus-first で一人でも多視点・一次情報主義

業界の図は、AとBとCを別々の流行語として並べがちです。私の主張は——この3つは、1つの世界観の3つの顔だということです。その世界観の核は、たった2つの原理に収束します。

1つ目は 「責任所在を architecture level に持ち込む」。Approval Bus も SafetyPolicy も証拠ラダーも、「気をつけよう」という運用根性論ではなく、迂回しにくい構造として実装する。第1章の @govern、第2章の SafetyPolicy、第3章の証拠ラダーは、すべてこの1点に奉仕しています。

2つ目は 「honest disclosure を核に置く」。異常に良い数字（「Bölük 10×」）が出たら、勝った気になる前に内訳を疑う。本記事の各章で、自分の数字（49k件、テスト90件、50手法 vs 96ノート）でも同じ作法を適用しました。

そしてこの世界観は、ローカルで完結します。RAD も llloop も RAPTOR も、すべて手元で動き、個人情報・企業機密・センサーデータを外へ出さない。なお、この自前スタック（llloop / RAD / RAPTOR）は、私が別途 FullSense と呼ぶ製品エコシステム（llmesh / llive / llove の 3製品 ＋ suite installer）とは別の、ローカルの研究スタックです。両者は思想を共有しますが、製品ラインとは一線を引いておきます（llive だけは、第3章で触れた LLM Wiki の受け皿として両者をまたぎます）。

なぜ「手綱を握るのは人間」だと言えるのか — 観察ベースの3点

最後に、第1章で予告した「優位性の論拠」をここに一本化します。ただし最初に正直に言うと、以下は 一次研究の引用に基づく measured な結論ではなく、私の経験に基づく観察（構造的傾向） です。「認知科学的に証明された」とは言いません。その上で、人間が構造的にAIより有利になりやすい点が、少なくとも3つあると考えています。

  1. 常時並列 … LLMは基本1セッション固定だが、人間は複数のことを裏で走らせ続けられる。
  2. 長射程の伏線回収 … LLMが回収できるのは1セッション内（数時間）の伏線。人間は 10年前の経験で立てた伏線を、今日回収できる。
  3. 常時稼働の危険予知（KYT） … LLMの risk_alert は明示的にコードを書かないと動かないが、人間は無意識で常時走らせている（ヒヤリ・ハットを「なんとなく」避ける、あの感覚）。

だから「手綱を握るのは人間」なのは、根性論というより観察された傾向です。そして私の llive は、この人間の傾向を、少しずつ architecture level に持ち込もうとしている——というのが、AとBとCを貫く動機です。

🗨️ 「社会とはこういう事でもあるのか… ルールが見えて来たぜ…」 — スナックバス江／フォビドゥン澁川（アル）

（閑話休題）「気をつけよう」という根性論ではなく、ルール（構造）で縛る。責任所在を architecture level に持ち込むという1つ目の原理は、つまり「見えてきたルールを、迂回しにくい形で実装する」ことなのです。

まとめ：手綱と、輪と、知

2026年、AI業界は prompt engineering の次に、harness engineering（手綱） と loop engineering（輪） を名付けました（発明したのはAIではなく、人間のエンジニアたちです）。私はその試作スタックを、概念実証レベルでローカルに持っています。

  • 手綱（A） … RAPTOR が「Python が全制御し、LLM は判断に専念する」2層分離で実装。そこに「人間が手綱を握り、AIを部下として育てる」という、モデル中心の図への補助線を足した。Karpathy 氏の "vibe coding"（2025-02）とは別系統で、「私が先に命名した」とは言わない。
  • 輪（B） … 自作 llloop（alpha・未公開）が MAPE-K で回し、現状の経路では迂回不可の fail-closed 安全層でブレーキを掛ける。LLMは提案しかできず、最終ゲートは SafetyPolicy。
  • 知（C） … 約65分野・約4.7万ノート（※5月集計時点）の RAD を、LLM Wiki パターンで育て（思考の循環には反循環の安全装置を付け）、RAPTOR が証拠の段階を守って安全に使う。

そして本記事を貫いたのは、ただ1つの作法でした。

異常にキャッチーな数字を見たら、勝った気になる前に内訳を疑う。一次情報に錨を下ろす。

「Bölük が 10× を示した」という、使いたくなる数字を、一次にあたって捨てた。これは弱点の開示ではなく、設計思想の一部です。手綱を握る人間に必要なのは、流暢な数字を見抜く「無知の知」だからです。

次回予告的な余韻

次に書きたいのは、第3章で「設計段階」と何度もヘッジした LLM Wiki の実装——llive Phase 2-4 の LLW-01〜08 と、RAPTOR corpus2skill の v2 化——の、実機での進捗です。「思考の循環」に反循環の安全装置を付けたうえで、知識が自分で育っていく様子を、動く絵で見せられたらと思っています。

手綱を握り、輪を安全に回し、知を育てる。その全部を、外部にデータを出さず、ローカルで。——それが、私の考える「2026年のパラダイム転換」の、地に足のついた姿です。

参考（出典）

harness / loop engineering（用語の一次・近一次）

RAPTOR（実物スタック）

関連記事（自著）

閑話休題（スナックバス江 / フォビドゥン澁川、アル）

※ 本文中でヘッジした「二次情報のみ／一次未確認」の主な項目は次の通りです：OpenAI 記事の本文・タグライン・規模数値（一次は HTTP 403）、LangChain の Agent = Model + Harness 式と各ハーネスベンチの計測元・計測条件（GPT-5.5 とされるモデル名を含む）、Claude Code v2.1.139 のリリース日、llloop のテスト緑の最新状態（再実行は未実施）、RAD 総 documents 数（「約49k」は2026年5月集計値）、Karpathy 氏 LLM Wiki Gist の提案者・日付、キヤノン「三自の精神」と First, Break All the Rules 4原則の出典頁、第3章の「人間優位3点」（measured ではなく観察ベース）。一次情報で確定でき次第、更新します。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?