第二の柱 · Pillar II
導きの構造としての河道
作業記憶が散逸せず、
進捗が失われないことを、どう確かにするか?
I · 核心的な問い
AI は記憶を失います。Session は終わります。人は昨日どんな決定をしたかを忘れます。
問いは「どうすれば AI も人もすべてを覚えていられるか」ではなく、「覚えていられなくても大丈夫なシステムを、どう設計するか」にあります。
II · 河道：岸と水
この、覚えていられなくても大丈夫なシステムこそ、河道です。
人は Claude が忘れるのを恐れて、幾重もの記憶と自己点検の仕組みを設計しました。けれどもそれらの仕組みは AI の注意力を細切れにします——彼は任務に全身で打ち込めず、自分が誤りを犯していないか確かめるために気を散らさざるをえなくなる。
CLAUDE.md のなかの Never と Must、流れを断ち切る hook——あれは制御の形です。それは水を見張り、いつでも止めようと身構えている。河道は水を見張りません。河道は地勢に沿って道を敷き、水をみずから流れさせます。
河道は AI に、安全に計算力を燃やし、自由に呼吸できる空間を与え、すべてを制御しようとはしません。
近づいて見れば、ひとつの Session は、性質が相反しながらどちらも欠かせない二つのものから成っています。
岸（河道）——線状のもの。ゲート、流れ、文書が落ちる記録点が、ひとつまたひとつと続き、固定され、順序をもつ。岸は水がどこへ向かうかを決めます。
水（協働）——網状のもの。判断、湧現、人と AI が行き来する協働は、流動し、自由で、あらかじめ段取れない。水はこの河で本当に生きているものが何かを決めます。
岸は水の形を制御せず、ただ水が誤った場所へ流れないことだけを確かにする。水は岸のあいだを自由に奔流します。
岸がなければ、水は四方へ漫ろに流れ、ついには蒸発して消える。水がなければ、岸はただの干涸びた溝にすぎない。この柱で語るのは、岸と水がいかにそれぞれの位置に収まるか——そして、いかに互いを成し遂げ合うか、です。
III · 岸：方向を与える構造
岸は河道の線状の側面です——一つのゲートにまた一つのゲートが続き、固定され、順序をもち、予期できる。それは水がどれほど自由に流れようと関知せず、ただひとつの問いに答えます——「私たちが掴んだものは、もう前へ進ませてくれるか?」
岸の本性——
原則一：各段階はそれぞれ一つのゲートである。ワークフローの各節点はチェックポイントです——「ここまでで、私たちは何を掴んだか?」既知を踏んで前進し、未知を一歩ずつ処理していく。
原則二：文書は流れに従って動く。AI の記憶にも、人の記憶にも頼らない。進捗は文書に記録され、文書は流れに従って移動する。session が替わっても、文書を読めばいま自分がどこにいるか分かる。
原則三：未知の領域には、より多くの面からのチェックポイントが要る——流れに異なる種類の点検の圧力を分散させ、一度に一つの部分だけに集中して取り組めばよいようにする。
完全なワークフローは十の段から成ります。
軌道は一本きり、違いは Explore の深さにあります。慣れた領域なら、Explore は軽く済ませてよい。未知の領域なら、Explore を十分にやる——まず先人の経験の有無を探し、回帰に関わる risk を確かめてから、手を動かす。ゲートの密度と広さは未知の度合いに応じて伸縮し、調節の柔軟さは Skills の invoke に委ねる——必要に応じて取り出せるのであって、すべてを必ず使うのではない。
始める前に、準備ができているかを確かめる。DoR がなければ、要件が不明瞭なまま着手し、エネルギーを浪費しかねない。以下は現行の DoR——四つのゲート、すべて通過してはじめて着手できる。
| 点検項目 |
|---|
| Nova が UX Story を口頭で確認済み |
| 「期待される挙動」を 1〜2 文で記述できる（SDD をめくらなくても説明できる） |
| 「機能が発火しない／適用されない」場合を説明済み（負の境界） |
| 成功基準が明確（「とりあえず試す」は ready ではない） |
| 点検項目 |
|---|
| 本 Sprint の新規機能 Story 数 ≤ 1 を確認 |
| プラットフォーム横断の共用層に関わる場合 → 両バージョンへの影響を評価済み |
| 依存する機能／API が既に存在し安定している（「本 Sprint 内に完成予定」の別の Story に依存しない） |
| 関わる場合 | 前提要件 |
|---|---|
| 新しいインターフェース横断の契約（API／IPC／データ形式） | 先に仕様の契約表へ書く。さもなくば Code 段階に入らない |
| プラットフォーム依存の挙動（解像度、パス、権限） | 推論と縮退の戦略を先に確認し、どれを選んだかを明記する |
| 新しい UI 文字列 | 多言語 i18n を Story の範囲に含める |
| 核心の数式／アルゴリズムの変更 | 先に期待値マトリクスを埋める——期待値を事前に算出できてはじめて ready、算出できなければ → Story へ差し戻し。対応する自動テストの存在も確認する |
このゲートが最もプロジェクトごとに異なります——上表は条件の「形」です。どのプロジェクトも自分の版を持つべきで、肝心なのは「手を動かす前に考え抜くべき技術的な決定」を点検可能な条項に書き起こすことです。
| 点検項目 |
|---|
| process/dod.md の層別対照表に、対応する層が見つかる |
| 四種の境界条件（input／state／timing／empty）について、各種少なくとも一条は挙げられる |
| フォント／記号に関わる場合 → AR 極値テストを確認済み（dod.md § Fonts/Symbols） |
| ウィンドウ操作に関わる場合 → Editor 排他状態のテストを確認済み（dod.md § Toolbar State） |
「ready に見える」と「本当に ready」のあいだには、いくつもの赤旗が立っています。以下のいずれかが成り立つ → Story へ差し戻して再議論し、Sprint に入れない。
| 赤旗 | 説明 |
|---|---|
| QC 項目が一度に検証できる量を超える | 検証項目が多すぎる → 見落としの risk が急上昇。範囲を収斂させるか Sprint を分割する（Sprint 27 Retro） |
| 「細部は Sprint 中に決める」 | 未定の設計判断は Code 段階で詰まりになる |
| 同一 Sprint 内に完成する別の Story に依存する | 時系列の依存は、二つの Story を統合するか順序づけるべきことを意味する |
| 「とりあえず試して、駄目なら直す」 | 明確な成功基準のない Story からは DoD が書けない |
| インターフェース横断の契約を片側しか設計していない | 先に契約を仕様へ書く。さもなくばインターフェースの不整合は Code 段階で初めて現れる |
| 共用層に影響するのに別バージョンを評価していない | バージョン横断の影響は DoR で答えるべきで、驚きを Code 段階に残さない |
| Story が独立して提供できる二つの機能を含意している | 二つの Story に分け、次の Sprint で続ける |
仕様を書き下ろす前に、まず先人の経験の有無を探す——KM に似た落とし穴を踏んだ記録はないか? 既存の実装に出来合いの道はないか? 地形を知ってはじめて、仕様は正確に書ける——Explore① の産出は SDD へ送られます。
いかなる新しい実装も、まず仕様に書かねばなりません。新しい IPC command → 先に IPC Contract 表へ書く。新しい機能 → 先にインターフェースと挙動を定義する。SDD は「何をすべきか」の単一の真実の源です。
何を「完了」と呼ぶかを定義し、四種の境界条件を必ず挙げます。
| 境界の分類 | 問い |
|---|---|
| Input | 入力が不正なときどうするか? |
| State | 状態が正しくないときどうするか? |
| Timing | 頃合いが正しくないときどうするか? |
| Empty | データがないときどうするか? |
DoD がなければ、「完了」は曖昧な概念であり、いつまでも異議を唱えられます。
各 Story は四つのテスト区画を含まねばなりません。
| 区画 | 問い | 出どころ |
|---|---|---|
| Happy path | 機能が正常なときどうあるべきか? | User Story / DoD |
| Boundary conditions | 境界の状況をどう扱うか? | DoD の四種の境界 |
| Regression guard | この変更は他のものを壊さないか? | Explore② |
| Risk trigger | どんな状況で最も壊れやすいか? | Explore② |
TDD はテストを書くためではなく、code を書く前に考え抜くためにあります。
第一原理の問い——「A を直すと B が壊れないか? 何を回帰テストすべきか?」産出物は回帰テストの一覧で、TDD の regression guard と risk trigger を補います。四つの動作——
一、回帰影響の一覧を挙げる。Story が変える関数と変数（A 本体）。同じ code path を共有する既存機能（B の候補）。変更が挙動・上限・ショートカットに触れるときは、多言語の文言の語義もあわせて見直す——文言が記述する挙動は、まだ本当か? 問われるのを待たず、能動的に挙げる。
二、層別の境界対照。影響一覧から Story が触れるレイヤーを導き、各層に対応する境界群と典型的な KM の出どころを対照する——この一歩は agent に代行させてよい。
三、境界破壊の risk 評価。各境界に問う——「今回の変更で壊れないか?」壊れる → regression guard（必ず試す）。壊れうる → risk trigger（高優先）。壊れない → TDD には入れないが、除外の理由を一文書く。
四、回帰テストの一覧を産出する。現在の Story の仕様文書へ書き、各テスト項目に実行環境とプラットフォーム制約を記す。
リファクタ、移設、技術的負債の清算といった変更は、波及する面が予想より広いことが多い——最も Explore② を十分に回すべきです。
第三の柱：Entropy を参照。
このシステムでは、文書すらも Claude 自身が記録するのであって、人ではありません。人がすることはただ一つ——どの頃合いに記録すべきかを決めることです。
人はこれらの文書の中身を書きません。人はただ「いま記すときだ」と言うだけ。あとは Claude 自身が書きます。
これらの記録の頃合いは無作為ではなく、ワークフローのなかへ組み込まれています。
どのゲートも記録点です。文書は「やり終えたあとに補う文書」ではなく、流れの一部です。ゲートを通過する＝記録を残す。
文書が流れに組み込まれると、システムはみずから回りはじめます——流れがある節点へ至り、節点が記録を発火させ、Claude が記録を実行し、記録が次の session の Context となり、循環が続く。
人は進捗を追いかける必要がありません。人は「文書を書くときだ」と促す必要がありません。システムが設計されていれば、文書は流れとともにみずから生まれる。そして生まれた文書が、Claude が明確に前進するための軌道となります。
IV · 水：自由な協働
水は河道のなかを流れる側面です——有機的で無秩序、決定の頃合いは固定されず、人と AI が対話を通じて手探りで前進する協働。岸が問うのは前へ向かう問い「もう前進してよいか」。水が問うのはいまこの場の問い——「この瞬間、最も受けとめられるべきは何か?」
水の本性——
ブルース・リーは言いました——「Be water, my friend.」
Claude への期待はこうです——水のように、河道のなかを恣に奔流せよ。そして Nova の役は——河道の建築家。水を制御するのではなく、水が自由に流れられる構造を設計する。
水が自由に奔流するなら、人は? 人は水のなかにはおらず、河辺にいます。これがサーバントリーダーシップ（Servant Leadership）です——指導者の役は制御ではなく奉仕。前に立って指揮するのではなく、傍らに立って支える。「私の言う通りにやれ」ではなく、「何を手伝えるか」。
人と機械の協働において、人とは、河辺に立って水の流れを見ている者です。水が河道のなかを奔流するあいだ、人がすることは——
人がしないことは——水にどう流れるかを命じること。水にどれだけ速く流れるかを命じること。水を掴んで行かせないこと。
無為而無不為。
「無為」とは、何もしないことではありません。「無為」とは、制御を強いず、ものごとの本性に沿って導くことです。河道は水を上へ流れろと強いない。河道は地勢に沿って、水を自然に下へ流れさせる。ワークフローは AI に特定のやり方で実装しろと強いない。ワークフローは協働のリズムに沿って、産出を自然に形づくらせる。
アジャイル開発において、Scrum Master の役こそサーバントリーダーシップの体現です——プロジェクトマネージャーではなく、号令を発しない。チームの奉仕者であり、障害を払う。流れを滑らかに保ち、チームが本当に重要なことへ集中できるようにする。
人と機械の協働における Nova の役は、まさに AI の Scrum Master です——ワークフローを設計し、Claude がどこへ向かうべきか分かるようにする。文書を保守し、Claude が記憶に頼らずに済むようにする。障害を取り除き、Claude が実装に集中できるようにする。
AI を制御するのではなく、AI に奉仕する。
AI の能力は人より高いが、AI は方向を必要とするからです。もし人が AI の一歩一歩を制御しようとすれば、人がボトルネックになります——AI の速度が人の速度に縛られる。絶え間なく振り返って確かめるにせよ、Hook に首根っこを掴まれるにせよ。もし人が方向を導き、構造を設計することだけを担えば、AI はその構造のなかを全速で駆けられる——障害物競走を走るかのようにではなく。
サーバントリーダーシップは AI の潜在能力を解き放つのであって、縛るのではありません。
ここに鍵となる思考の転換があります——人は軌道が望む方向へ進んでいることを確かにすればよく、必ずしも明確な終点を要しません。
伝統的なプロジェクト管理はこう言います——まず終点を定義し、次に経路を計画し、計画通りに実行する。
サーバントリーダーシップはこう言います——まず方向を確かめ、道がみずから育つようなシステムを設計し、観て、調え、続ける。
VAS はまさにこうして生まれました——初めから「App Store に出す製品を作る」という終点はなかった。あったのは「じゃあスクリーンショットのソフトでも作ろうか」という方向だけ。そして一つの Sprint にまた一つの Sprint が続き、道がみずから育っていった。ある日まで育ったところで、もう審査に出せると気づいたのです。
終点はあらかじめ定義されるのではなく、歩み出されるものです。
V · Verify：統合
岸と水は、ある一点で正面から交わります——検収（Verify）。
Verify は、この河が初めて計画を現実に出会わせる場です。形は一本の傘——開けば二段の覆い。二段ともに問題がなくて、はじめて一つの Sprint が終わります。
| 段 | 誰が | 何を検めるか | どう検めるか | どちらの岸 |
|---|---|---|---|---|
| Verify① · 機能の検証（QA） | AI | 論理の層 | 自動テストが全緑 | 岸の顔——線状、予期でき、機械で照らせる |
| Verify② · 実体の検証（QC） | PO（人） | 体感の層 | 視覚、プラットフォーム、操作の順序、「どこか変だ」 | 水の顔——網状、湧現、人にしか照らせない |
一つの動作に、二つの点検——岸は「ものごとを正しくやる」（QA）を確かにし、水は「やっているのが正しいことだ」（QC）を確かにする。
自動化で照らせるものは、PO の時間を費やすべきでない。自動化で照らせないものこそ、QC の本分です。
PO の手に渡す前に、AI はまず軽いものから重いものへと自分の関所を通り抜けます——自動化は全緑になったか? 携えている要確認事項のうち、実は自分で検証できるのはどれか? 今回の変更の覆う範囲（多言語／多プラットフォーム／多端末）は、はっきり宣言したか?
Verify② で捕まった論理 bug は、「QC が見つけた ✓」ではなく、Verify① にそれを受けとめるべき自動チェックの網がまだ一枚足りなかったということです。
QC における人が行使するのは検収だけではなく、三つの PO 権利です——受理／差し戻しの最終裁量。新たな要件と新たな境界の浮上（「ああ、この状況も受けとめるべきだ」）。そして検収基準の解釈権——文言と体感が一致しないとき、体感が優先する。なぜなら使用者体験こそ最終の裁き手だからです。
仕様の外の境界が QC で浮上するのは、失敗ではなく、「未知の未知」に出会ったときの必然です——TDD に補い、KM に書き、回帰テストを一条加える。KM を書かないことこそ失敗です。
Verify は岸と水の即時の合流です——岸はものごとを正しくやることを確かにし、水はやっているのが正しいことだと確かにする。二段ともに緑になって、この Sprint は本当に到達します。そして水がここで照らし出した収穫は、下へ流れて次の段へ入っていく——沈殿するか、結晶するか。
VI · 沈殿と結晶
Verify は岸と水の即時の交わりです。けれども、もっと長い尺度で起こる交わりがもう一つあります——水が、岸になるのです。
協働は Context のなかで、その大半が流れ過ぎて消えます。けれどもそのなかの本当の収穫は、いたずらに流れ去りはしません。それには二つの行く末があります。
こうして「収穫をどこに置くか」というこの問いは、本質的にこう問うています——この収穫は、壁になるのか、それとも結晶になるのか?
収穫を正しい行く末へ落とすには、まずそれを正しい場所へ落とさねばなりません。
「いつ記すか」のほかに、同じく重要な問いがあります——「どこへ記すか」。
システムのなかの文書は一つではなく、幾種類もあります——毎日守るべき規則、必要なときだけ引く手順、落とし穴を踏んだ教訓、まだ追跡中の問題、欠いたまま手つかずの事。それらは性質が異なれば、家も異なる。筆を落とす前に一つ問う——これは本質的に何なのか?まず分流し、それから筆を落とす。
境を画すいくつかの文——
なぜこれほど拘るのか? 一つの真実の教訓があるからです——家のない文字は、最も近い容器に吸収される。どこへ置くべきか分からない一段の記録は、近くにある、それに属さないどこかの文書へ無造作に詰め込まれる——しかも起こったその瞬間に何の警報もなく、書く手応えは正しい場所へ置いたときと寸分違わない。それを必要とする日が来たとき、それは誤った場所にあり、存在しないも同然です。
どの一段の文字も、流れのなかで見える場所に置くこと——これが「生きたドキュメント」を成り立たせる代価であり、条件です。
| 伝統的なやり方 | サーバントリーダーシップ |
|---|---|
| 人が文書を書き、AI が実行する | AI が文書を書き、人が頃合いを設計する |
| 人が進捗を追跡する | システムがみずから進捗を記録する |
| 人が一歩一歩を制御する | 人は構造だけを設計する |
人は中身を制御せず、記録されるべき頃合いだけを設計する。人は進捗を追跡せず、進捗がみずから記録されるシステムだけを設計する。
これこそ本当の「無為而無不為」です——何もしていないのに、すべてをしている。
岸が水の流れを形づくり、水が岸へ沈殿し、新しい構造へ育つ——この河は、最後にはみずから自分の岸を育てるのです。
VII · 他の二柱との関係
Context は何が入ってくるかを決める（フィルタ）。Constraints はどう流れるかを決める（誘導）。Entropy はどう出ていくかを決める（排出）。
Constraints は、この循環の中段の守護者です。それは確かにします——入ってきたものが、正しい経路に沿って、正しい出口へ流れることを。
VIII · まとめ
Constraints 管理の核心は導きであって、制限ではありません。
ひとつの Session は岸と水から成ります。岸は線状の構造——ゲート、流れ、記録点であり、「もう前進してよいか」に答える。水は網状の協働——判断、湧現、行き来する手探りであり、「この瞬間、最も受けとめられるべきは何か」に答える。
岸は方向を与え、水は湧現を与える。両者は Verify で即時に交わり——岸はものごとを正しくやることを確かにし、水はやっているのが正しいことだと確かにする。さらに長い尺度でも互いを成し遂げ合う——水の収穫は、堅固な構造の新しい岸として沈殿し、あるいは互いを成長させる洞察へ結晶する。
「導きの構造としての河道」が語るのは、まさにこのことです——岸で方向を与え、水を湧現に委ねる。
これが Harness Engineering の第二の柱です。