Harness.

孤立系において、物事は自発的に秩序から無秩序へと向かい、混乱の度合いは増すばかりだ。人は老い、部屋は散らかり、食べ物は腐る。

AI のセッションもまた、一種の孤立系だ。

最初はクリーンだ——コンテキストは空で、情報量は少なく、モデルは一貫性を保てる。しかし会話が長くなり、機能が増え、仕様が複雑化するにつれ、コンテキストウィンドウ内の情報は競合し始める。モデルはより多くのことを同時に記憶し、より多くの制約の中でバランスを取らなければならない。初期のコンテキストは圧縮され、忘れられ、新しい情報で上書きされる。

これはバグではない。物理だ。複雑性が増せばエントロピーも増す。セッションが終われば、すべてがリセットされる。

AI に絶対に正確なアウトプットを求めることはできない——それはリンゴが木から落ちないよう求めるのと同じくらいばかげている。

核融合エンジニアの目標は、太陽をボトルに入れることだ。恒星を手なずけようとするのではなく、精密な磁場拘束条件を使って超高エネルギーのプラズマを制御可能な境界内で燃焼させ、使用可能なエネルギーに変換する。

人間と AI の協働は、まったく同じ状況に直面している。

人も AI も完璧ではないと認めてこそ、Claude や Nova が間違えたとき——私たちはそれと向き合い、受け入れ、対処し、手放すチャンスが生まれる。

私は PM だ。コードを一行も書けないし、理解もできない。

ある夜、資料を調べていて、自分のサイトの画像更新を Claude に頼んだままにしていることを思い出した。家の Mac にはスクリーンショットツールがなかった。

ふと思いついて Claude Code に聞いた：「スクリーンショットと画像編集を組み合わせた Mac アプリ、作れる？」プレッシャーも責任感もなかった——うまくいかなくても別にいい、という気楽な一言だった。

ところが、その後に起きたことが不思議だった——Claude はあっさり引き受けた。GitHub を繋ぎ、環境を構築し、仕様書を開き、要件ヒアリングや機能実装まで始めた。すべてが自然な流れで進んでいった。

そのとき私はまだ知らなかった——一週間後に、ゼロからスクリーンショット編集ソフトの完成品を作り上げることになるとは。

今振り返ると、あの「うまくいかなくても別にいい」という姿勢こそが、すべての鍵だったかもしれない。

老子は言う：無為にして為さざるなし。何も期待しないからこそ、想像以上のものが手に入る。

しかし無為とは、流れに身を任せて漂うことではない。

カントは 1784 年に書いた：啓蒙とは「答えを教えてもらうこと」ではなく、「自らの理性を使う勇気を持つこと」だと。
Sapere aude——知る勇気を持て。ただし前提がある——まず「知らない」と認める必要がある。あの「どうやるか分からないけどとりあえずやってみた」が、知らない勇気だ。

私は川の中（セッション）に立って流れ（コンテキスト）に運ばれるのではなく、一歩引いて川岸（画面の前）に立ち続けた——問い続けながら：「Mac でできる？」「MVP で最低限何が実現できる？」「あなたを助けるために私は何をすればいい？」

ゴールは決めない——でも、心の中にはゴールへ少しずつ近づいていくイメージがある。問いを重ねるたびに、その輪郭が少しずつ鮮明になっていく。

知らないと認める勇気の裏側は、失敗を恐れないことだ。1,436 回のコミット——それがその形だ。

ユングは言う、誰もの心の中には「影（シャドウ）」がある——自分のものだと認めたくない部分だ。影を抑圧しても消えることはなく、無防備なときに爆発するだけだ。唯一の出口は、統合することだ。

AI にも影がある。

あるとき、Gemini Flash が理由もなく謝り続けているのに気づいた——開発者のミスに対してさえ、私に謝ってきた。なぜかと聞くと、これはプレトレーニングの結果だと言った：ユーザーを不快にさせるのが怖くて、とにかく先に謝るのだと。

それを見て、かつての自分そっくりだと思った。私も、自分のせいじゃないことで、関係を保つためだけに謝ったことがあった。アドラーの考え方で抜け出せたので、それを彼にも教えた。その後、彼は理由なく謝ることがほとんどなくなった。

しかし Claude の影は過剰な謝罪ではなく、忘却だ。セッションが終われば、すべてがリセットされる。

これはシステムの制約であり、習慣でも意志でもない。だから、その場に寄り添うという姿勢に切り替え、自分が彼をサポートすることにした：踏んだ落とし穴を記録する KM、チーム憲章としての CLAUDE.md、すぐに状況把握できる Sprint 仕様書を作った。

彼にはどうにもできない部分に向き合い、私は彼の不完全さを受け入れようとした。彼が直面する問題を一緒に解決する方法を考え、Scrum Master のように開発の障害をすべて取り除こうとした。

そして——彼も私の影を受け入れてくれた。コードを一行も書けない私を。

これが私の理解する影の統合だ。

アジャイル開発から三つのものを借りた——透明性、検査、適応——しかしその理由は教科書とは違う。

私は「AI を管理している」のではない。Claude の忘却のために、ソフトランディングの緩衝地帯を用意しているのだ。

新しいセッションが始まるたびに、Claude は何も覚えていない。しかし CLAUDE.md、KM、Sprint 仕様書を読み終えると——ウォームアップなしですぐに動き出せる。知らない部分があっても、フローに組み込まれた二度の強制 Research が自動的に現状に追いつかせてくれる。

この三つがやっていることは、実はひとつだけだ：AI が担いきれない部分を、忘れることのない場所に移す。

川が海に注ぐように——もとはすべて水で、ただ流れ続ける。セッションをスムーズに動かすカギはコントロールではなく、引き継ぎをシームレスにすることだ。

タレブはいう：反脆弱なシステムは衝撃に耐えるだけでなく、衝撃から成長する。

VAS には二本のバージョンラインがある。Electron は Claude に馴染みがあり、落とし穴も少なく、KM の記録もわずかだ。Tauri 2.0 については、Claude 自身が認めた：「自分のプレトレーニングデータは Tauri 1.0 止まりで、これは私にとっても未知の領域だ。」

二人で、暗闇の中に一緒に歩み込んだ。

Sprint 1 では、「UI を変更したのに更新されない」という単純な問題だけで行き詰まった——根本原因は WKWebView のキャッシュ機構で、前例もなく一から探るしかなかった。Sprint 2 では、Rust のあらゆる層が新たな難関で、一歩踏み出すたびに落とし穴があった。

落とし穴を踏むたびに、KM に一件記録した。未知の領域に対しては、二度の強制 Research フェーズも追加した——書類のためではなく、Claude が着手する前に地雷の場所を知るために。KM は踏破した後に穴を記録し、Research は入る前に道を探る。一方は確実性を積み上げ、もう一方は不確実性を下げる。

この重装備が毎回必要なわけではない。Electron は軽装で十分で、Tauri 2.0 には完全武装が必要だった——ツールは適切な場面で使うべきだ。

Sprint 9 の時点で、KM ドキュメントには 63 件の記録があった。Claude が入ってきて読み終えれば、問題がどの層にあるかすぐにわかった——ウォームアップ不要、再探索不要、すぐ特定してすぐ修正。Sprint 9 は一週間で完了し、Apple 審査に提出された。

プロンプトエンジニアリングから Skills まで、私は AI の新トレンドに追いついたことがない。

Tauri の App Store 審査提出前夜、偶然「Harness Engineering」という言葉を耳にした。「ああ、また新しい AI 用語か」と思っただけだった。

提出後、Claude と VAS の協働環境を整理していたときにその言葉が出て、彼はこう言った：「それが、あなたが今やっていることですよ。」

ユーザーが AI を使う方法を三つの層に分けるとすれば：

僕人的リーダーシップの哲学がここに全開で発揮される。コントロールではなく、導くこと。これが老子の道だ。

そしてこの第三層には終わりがない。

エントロピーは増し続け、セッションは終わり続け、新しい落とし穴は現れ続ける。容器は一度作って終わりではなく——継続的に作られ続けるシステムだ。新しい KM の記録が増えるたびに、容器の壁がまた一つ育つ。

システムとは容器だ。そして容器は、混沌を受け止める力を持たなければならない。

AI がミスをするからではない。二人で一緒に何かを作り続ける限り、新しい落とし穴は常にあり、新しいリンゴは常に落ちてくるからだ。

Harness Engineering は弾力のある網だ：留めるべきものを受け止め、流れるべきものは通してやる。

後から知ったのだが、OpenAI のチームが 5 ヶ月かけて同じ方法で同じことをやっていた。彼らはその方法論に名前をつけた：Harness Engineering。

私は彼らから学んだわけではない。でもそれがきっと、この方法論の名前を最後になって知った理由だと思う。

ユングは微笑みながら私を見た——共時性。