AIと協働し、複利のように積み上げて成長する方法

• AIとの協働における コンテキスト提供、嗜好設定、検証の自動化、委任の拡大、フィードバックループ という5つの原則を体系的に整理した実務ガイド
• すべての作業成果物（コード、文書、分析、意思決定）が次のセッションの コンテキストとして蓄積 され、修正事項が設定に反映されて将来のエラーを減らす複利構造
• CLAUDE.md、スキルファイル、ガイドなどを活用して モデルの振る舞いとワークフローをコードのように管理 する具体的方法を提示
• 並列セッション運用、モデル間の相互検証、リモート制御 などにより作業処理量を拡張する委任戦略を含む
• これらの原則はAIだけでなく、人間のチーム協働にも同様に適用可能 な汎用フレームワーク

---

コンテキストをインフラとして構築する

• すべてのコードを ~/src に、知的作業を ~/vault（projects/, notes/, kb/ など）に整理すると、モデルが grep や glob でコンテキストを検索 しやすくなる
• 組織のコンテキスト（Slack、Drive、Mail など）を MCP(Model Context Protocol) でモデルに接続可能
  • プロジェクトごとに INDEX.md を維持し、各項目に URL、担当者、内容説明を 注釈として記録 する
  • 単純な URL 一覧ではモデルがすべてのリンクを開く必要があるため、注釈を付けておくことで コンテキストの浪費を防止 できる
• 新しいセッションごとにモデルは白紙状態から始まるため、プロジェクトごとの CLAUDE.md を 新メンバー向けオンボーディング文書のように 作成する必要がある
  • 略語用語集、プロジェクトコードネーム、同名人物の区別などを含める
  • INDEX.md → TODOS.md → 特定トピックのノートという順で 読む順序を指定 する
• メモリレイヤーを2種類に分けて運用する
  • ~/vault: プロジェクト状態、成果物、ドメイン知識などの 事実情報(facts) を保存
  • ~/.claude（CLAUDE.md, skills/, guides/）: 嗜好、ワークフロー、個人的好みなどの 設定(configuration) を保存

嗜好を設定としてエンコードする

• ~/.claude/CLAUDE.md の活用

  • すべてのセッション開始時に Claude が読む 行動契約書 の役割を果たす
  • 率直に話すこと、同意できないときは反論すること、不確実なときは正直に伝えること、失敗時は根本原因を調査してから再試行すること、作業範囲外のリフォーマット禁止などの 行動ルール を含める
  • 新しいシステムやドメインの中核用語が出たら1〜2文で説明する teaching セクション を設定することもできる

• ディレクトリごとのスコープ分離

  • グローバル（~/.claude/CLAUDE.md）: 振る舞い、長期目標、学習嗜好など、どこでも適用される設定
  • リポジトリルート: lint、命名、PR 規約などリポジトリごとのルール
  • プロジェクトディレクトリ: ディレクトリ構造、ドメイン知識などプロジェクト固有のコンテキスト
  • Claude Code は下位ディレクトリから開始すると ツリーを上にたどりながら各 CLAUDE.md を読み込む

• CLAUDE.md が長くなったときの分離戦略

  • 長い CLAUDE.md は毎セッション全体を読み込む コンテキスト税 になる
  • @import の代わりに、CLAUDE.md に「関連時に読む」という形で ガイドファイルのパスだけを記載 して遅延読み込み(lazy loading)を実現する
  • 例: 文書作成時は ~/.claude/guides/writing.md、評価作業時は ~/.claude/guides/evals.md など

• 週1回以上繰り返す作業はスキルに変換

  • スキルは名前、トリガー、手順を含む Markdown ワークフローファイル
  • /polish: アーティファクト diff を見て、メトリクスがあれば eval を実行し、ブラウザレンダリングなら Chrome で確認し、そうでなければコードを実行して出力・エラーを確認 → 繰り返した後に PR 草案を作成
  • /write: アウトライン面談 → リサーチ用サブエージェントを作成 → 草案作成 → 敵対的批評者としてフィードバック → 反復
  • /daily: カレンダー、Slack、PR、前日のログを読み、今日の優先事項を作成
  • SKILL.md はワークフローとルーティングに集中し、テンプレート・スクリプトなどの知識は別ファイルに分離して 必要時のみ読み込む

• スキルのブートストラップ方法

  • 作業を一度対話的に実行した後、モデルに スキルとして作ってほしいと依頼 する
  • 同一または類似の作業でスキルを実行し、出力の修正は 同じセッション内で 行う
  • モデルに修正とフィードバックをもとにスキルを更新するよう依頼する
  • 望ましい出力の 例を提供 して、パターン（コード構造、文書構造とトーン）を抽出させることもできる

• トランスクリプトによるスキル改善

  • 最初のバージョンが元のセッションに 過剰適合(overfit) するのは正常
  • SKILL.md を直接編集せず、セッション内で修正して before-and-after の対がトランスクリプトに蓄積 されるようにする
  • 出力に満足したら、モデルにフィードバックをスキルへ統合するよう依頼 → 数ラウンド後にスキルが 収束 する

• すべての作業にこのコンテキストが必要なわけではない

  • ブレインストーミング、探索、草案作業には シンプルモード（CLAUDE_CODE_SIMPLE=1 claude）を使う
  • CLAUDE.md は読み込まれるが、エージェントハーネス（フック、スキル、ツールループ）は無効化され、モデルにより近い形で思考できる

自律性のための検証

• 検証を左に寄せる(shift left)

  • 検証を はしご構造 で構成する。下段は安価で決定的、上段はコストが高く判断を要する
  • 最下段: モデルが修正したファイルに ruff format, ruff check --fix を実行する post-edit フック → 決定的でトークンコストなし
  • 上位段階: テスト、eval、LLM レビュー など

• モデルが自分で作業を検証できるように構成

  • システムがメトリクスを生成するなら、モデルが eval を直接実行 して最適化できる
  • ブラウザレンダリング出力なら Claude in Chrome で検査
  • Docker イメージのビルド時はエラーを読み、Dockerfile を修正して再ビルド
  • ダッシュボード構築時はツールチップ描画、ラベル重なり、数値とナラティブの整合性を Chrome で確認 する

• 長時間作業ではモデルがモデルを監視

  • 長いセッションではエラーが蓄積し、ドリフト が起こりうる
  • 解決策: 2つ目のセッションを新鮮なコンテキストで実行し、元の仕様と1つ目のセッションの直近ターンを比較する
  • tmux の2ペイン 構成: 1つは一次開発、もう1つはペアプログラマー
  • 共有ファイルに初期指示と後続プロンプトを追加しながら、ペアプログラマーが定期的に確認する
  • 実行ドリフト(execution drift): モデルが作業を正しく実行しているか — エラー無視、誤ったメトリクス報告、仕様逸脱などの 戦術的チェック → 頻繁に確認
  • 方向ドリフト(direction drift): モデルが正しい作業をしているか — 元の意図を誤解して間違ったものを作る 戦略的問題 → ときどき確認

委任による拡張

• 徐々に大きな作業単位を委任する

  • 短い作業と速いフィードバックの ペアプログラミング 方式は、高速反復、探索的分析、プロトタイピングに適している
  • より強力なモデルには、意図、制約条件、成功基準 を事前に説明し、モデルが end-to-end で実行するよう委任すべき
  • 検証できないものは委任できないため、成功基準とメトリクス定義が先行 する必要がある
  • 例: 「eval スイートごとの分離コンテナをビルドしてスモークテスト → 全体実行 → メトリクスとトランスクリプトをロギング → サブエージェントで正確性確認 → n回反復して 信頼区間 を算出 → レポート生成後 Slack に結果送信」

• 並列セッション運用とボトルネックの把握

  • 大きな作業の委任によって同時に 3〜6セッション を並列実行できる
  • ボトルネックは「作業実行」から 「明確な仕様作成と高速な出力レビュー」 へ移る — 中間工程が空洞化する構造
  • 並列セッションが同じリポジトリを共有する場合は、git worktrees を使って各セッションが独立したチェックアウトを確保する

• セッション観察のしやすさを確保

  • stop hook: セッション完了時にサウンドを再生（macOS では afplay で Glass.aiff を再生）
  • tmux ウィンドウタイトル: 状態絵文字（⏳ 作業中、🟢 完了）と Haiku が生成した短いラベルで各ペインを識別
  • Claude Code ステータスライン: コンテキスト使用量と現在モードを表示

• 離席中でもチェックイン可能

  • Claude Code の /remote-control 機能により、移動中でも Claude アプリのコードタブから実行状態を確認し、詰まったセッションに追加コンテキストや新しい指示を与えられる
  • セッションが何時間もアイドル状態で放置されるのを防げるが、緊急時にのみ使う

フィードバックループを閉じる

• 公開的に作業してコンテキストを豊かに保つ

  • 共有文書、リポジトリ、チャンネルで作業すれば、モデルを含む チームの全員がコンテキストを活用 できる
  • 簡単なテスト: 「新しいチームメンバーが共有されたコンテキストだけで先週の自分の作業を 再現できるか？」 — できないなら重要なコンテキストが頭の中にしかない
  • CLAUDE.md に、実質的な作業完了時はワークログチャンネルへ 短い更新とアーティファクトリンクを自動投稿 するよう指示する

• トランスクリプトをマイニングして設定を更新

  • 過去セッションのトランスクリプトをモデルに読ませると ギャップを発見 できる
  • 約2,500件の過去ユーザーターンをスキャンした結果、かなりの割合が "can you also…", "did you check…", "still wrong" といった表現を含んでいた
  • これはモデルが 自発的に行うべきだった作業 か、検証段階が欠落・誤作動していたことを示唆する
  • 修正はセッション内で行い、トランスクリプトを次の CLAUDE.md やスキル更新の 入力データとして活用 する

• 定期的にリファクタリングと整理を行う

  • 設定が増えると互いに 重複したり衝突 したりする可能性がある
  • モデルがルールを無視する場合は他のルールとの矛盾が原因かもしれないため、各ルールや嗜好は 正確に1か所だけ に存在するようリファクタリングする（重要な指示はメインの CLAUDE.md に重ねて書いてもよい）
  • 散在するディレクトリ別 settings.json を ~/.claude に 統合整理 する

結論

• 具体的な設定はモデルの進化とともに変わりうるが、良いコンテキスト提供、嗜好のエンコード、低コスト検証、より多くの委任、フィードバックループを閉じる という原則は有効
• この過程は結局のところ 協働相手をフィードバックを通じて一歩ずつ訓練していくこと であり、人間チームとの協働にも同様に適用できる
• 個人ツールに限らず、エージェントハーネス設計、チーム規範の設定、組織インフラの構築 にも同じ原則を適用できる

[xguru]

この人の経歴が面白くて、
心理学専攻から Coursera のデータサイエンス講座で学習
東南アジアのAmazonと呼ばれたLazadaの初期に参加し、VPまで昇進。
LazadaはAlibabaに買収された。
その後Amazonに移り、レコメンド/LLMの主任サイエンティストに。
現在はAnthropicのテクニカルスタッフ