1. 知識が揮発する、3つの経路

こんにちは。『ホットペッパーグルメ』開発グループマネージャーの永井です。

こんな心当たりはないでしょうか。「あとで読もう」が積み重なって、結局読まないまま忘れてしまう。なんとなく考えてはいるのに、いざアウトプットを求められると言語化に手が止まる。「誰かが検討してくれていたはず」なのに、もう聞ける人がいない。

私はこれを、知識の 「揮発」 と呼んでいます。そして揮発には、3つの経路があります。

経路1: 流量で揮発する。 技術記事、社内ドキュメント、Slackのスレッド、障害報告、アーキテクチャの議論。日々流れてくる情報は膨大で、すべてに目を通すことは不可能です。気合を入れて書いたConfluenceのページも、数ヶ月後にはコードと乖離して「あのWiki、まだ信用していいんだっけ？」という確認作業が日常化する。やがて誰もWikiを更新しなくなり、情報はさらに散逸していきます。知識が流量に負けて揮発していく。

経路2: 言語化されず揮発する。 「あの件、資料にまとめておいて」と言われてから慌てて書く。日常的に考えていることが言語化されていないから、毎回ゼロから構成を考える。頭の中にある意思決定の根拠、ドメインの暗黙知、アーキテクチャの判断理由 — 言語化されなかった知識は、時間と共に揮発していきます。

経路3: 人と共に揮発する。 障害対応で得た知見、アーキテクチャの判断根拠、技術選定の背景。Slackのスレッドに埋もれ、退職と共に消えていく。「いつか整理しよう」と思ったまま忘れ、組織は同じ失敗を繰り返し、同じ議論を何度もやり直す。知識が人に属している限り、人と共に揮発します。

AIを活用して、日々の情報を受け止めつつ自分の思考を揮発させずに深める方法を自分なりに模索しています。本記事では、マークダウンファイルの構造設計を通じてこの「揮発」に抗う実践知を共有します。

2. 揮発を防ぐ「器」をつくる

私自身、細かく情報を読み取ったり精緻に計画を描いたりすることは得意ではなく、事業が抱える課題感を集めて、解決のピースを揃えて突破するところに楽しさを感じるタイプです。社内でCursorやClaude Codeを使うようになり、情報の整理はAIの力を借りて進めることを試みてきました。

具体的には、日々のインプットをマークダウンで受け止めて、AIを使って分析する。気づきもAIに整理してもらいながら思考を深めていく。戦略やタスクの進捗確認もAIと一緒にやる。この一連のワークフローを支えるリポジトリを、canvas と呼んでいます。揮発を防ぐための「器」です。

続けていくうちに、うまく回る構造にはパターンがあることに気づきました。事実と解釈が分離されていること。意思決定の根拠が残っていること。循環する仕組みがあること。この3つの性質を意識して育ててきた構造を、ITSA（イッツア）モデル と名付けました。

3. ITSAモデル — 4つの層でナレッジを構造化する

ITSAモデルは、4つの層でナレッジを構造化します。GitリポジトリのディレクトリがそのままITSAの層になるのがポイントです。

canvas/
├── 00_inbox/          # 未整理の思考・課題の投下口
├── 01_identity/       # 哲学・規律
│   ├── policies/          # 組織方針
│   ├── lessons/           # 過去からの学び
│   └── discipline/        # 開発規律
├── 02_telemetry/      # 観測事実（不変の記録）
│   ├── domain/            # ドメイン全体地図
│   ├── codebase/          # コードベースの構造
│   ├── incidents/         # 障害・事象記録
│   └── decisions/         # 意思決定の不変記録（ADR）
├── 03_strategy/       # 診断（構造的課題の分析）
│   ├── ISS-001_xxx.md     # 個別Issue
│   └── ...
└── 04_action/         # 実行（アクション群）
    ├── roadmap/           # ロードマップ
    ├── modernization/     # モダナイゼーション
    └── research/          # 調査・研究

各層には設計思想があります。

Inbox（受け口） — 考えていることをまず放り込む場所です。AIと会話しながら整理し、適切な層に移していく出発点になります。

Identity（哲学） — 自分たちが何を大切にしているかを言語化する層です。組織方針、過去からの学び、開発規律。意思決定の根拠がここにあります。

Telemetry（観測） — 起きた事実を記録する層です。「レイテンシ 1500ms」は事実、「キャッシュを導入すべき」は解釈。この分離により、AIが偏りのない分析を行えるようになります。

意思決定の記録（ADR: Architecture Decision Records）もこの層に置きます。「キャッシュを導入する」と決定した瞬間、その判断は覆らない事実になる — と考えて、Telemetry層に置いています。

Strategy（戦略） — 事実と理想の乖離を診断する層です。構造的課題をIssuesとして起票し、根本原因を分析し、解決策を導きます。「なぜその判断をしたか」は、ADRとしてTelemetry層に刻まれます。

Action（実行） — 戦略に基づく実行計画です。

各層の内部構造は、組織や個人の状況に合わせていろいろな形に変わります。ITSAは特定のディレクトリ構成をコピーするテンプレートではなく、4層の分離原則です。環境に合わせて自由に調整します。

4. 運用サイクル — 知識が「育つ」仕組み

ITSAモデルの本質は、静的なフォルダ分けではなく、循環サイクルにあります。

このサイクルの中で最も重要なのが 昇華（Ascension） — 実行結果をIdentityに還元するプロセスです。

具体例を挙げてみます（詳細は抽象化しています）。

ある大規模プラットフォームで、特定機能の障害が発生しました。Telemetry層に事象を記録します。この障害は事業KPIに直撃し、温度感が高い — つまり、障害レベルや事業への影響、根本原因の構造的な匂いから判断して、即座に構造的分析に持ち込むべきパターンです。

ここで重要なのは、「暫定対処で終わらせない」ことです。温度感の高いパターンは、まずStrategy層のIssuesで構造的課題として診断し、解決策が確定したらADRとしてTelemetry層に不変記録を格納します。そしてAction層で構造的解決策を実行に移します。

実行が成功したら、その知見をIdentity層の開発規律として昇華させます。「同種の新規プロジェクトはこの規律に従う」。これにより、同様の障害を構造的に防げるようになります。

この例は障害を起点にしていますが、サイクルの入口はそれだけではありません。計画的な観測から始まるフローもあります。

あるプロジェクトで、複雑なドメインのデータベース戦略を策定する必要があったとします。まずTelemetry層にドメインモデルの全体地図を作成し、エンティティの特性（更新頻度、参照パターン、整合性要件）を事実として分類・記録します。次に、この観測結果を入力としてStrategy層で構造的課題を診断し、「高頻度更新データはドキュメントDB、強整合性データはRDBMS」といった配置方針をADRとしてTelemetry層に格納します。ADRにはドメインマップへの明示的なファイル参照を記述し、「なぜその判断に至ったか」の双方向トレーサビリティを確保します。そしてAction層で段階的マイグレーションを実行する。起点が違っても、同じT→S→A→Iのサイクルが回るのです。

偶発的に得た学びを、設計された組織の進化に変える。それが「育てる」の意図です。

5. 個人から組織へ — 構造が同じだからスケールする

ITSAモデルの興味深い特性は、個人利用と組織利用で構造が変わらないことです。変わるのは粒度だけ。

個人リポジトリ

canvas/
├── 00_inbox/           # 日々の気づき・アイデア
├── 01_identity/        # 自分の哲学・価値観
│   └── me.md           # 「自分はどうしたいか」
├── 02_telemetry/       # 読書メモ・学習記録
├── 03_strategy/        # キャリア戦略・技術選定
└── 04_action/          # 個人アクション
    ├── business/       # 仕事関連
    └── hobby/          # 趣味

組織リポジトリ

canvas/
├── 00_inbox/           # 未整理の組織課題
├── 01_identity/        # 哲学・規律
├── 02_telemetry/       # ドメイン地図・障害記録・意思決定記録
├── 03_strategy/        # 構造的課題の診断
└── 04_action/          # 組織アクション群
    ├── roadmap/        # ロードマップ
    ├── modernization/  # モダナイゼーション
    └── research/       # 調査・研究

個人の価値観は、組織方針に対応します。個人の読書メモは、組織のドメイン地図に対応します。個人のキャリア戦略は、組織の構造的課題分析に対応します。

構造が同じだから、粒度だけ変えればスケールします。 個人で実践して手触りを確かめ、そのまま組織に展開できます。新しいフレームワークを学び直す必要がありません。

私の場合、個人リポジトリと組織リポジトリを並行してITSAで運用しています。構造が同じなので、CLAUDE.md（AIへの指示書）もほぼそのまま流用できました。

組織Aから組織Bへ — ITSAのポータビリティ

「個人→組織」だけではありません。私は異なる環境間でもITSAモデルを適用してきました。技術スタックもドメインも組織規模もまったく異なる複数の環境です。

各層の中身は当然変わります。観測対象も、診断する課題の性質も、実行計画の粒度も異なります。

しかし、変わらなかった点のほうが重要です。4層の基本構造、事実と解釈の分離原則、昇華サイクル、そしてCLAUDE.mdの優先参照ルール — ITSAの骨格はそのまま機能しました。フレームワークの価値は「テンプレートの再利用」ではなく「設計原則の再現性」にあります。

6. Claude Code — 戦略パートナーとしてのAI

ITSAモデルの運用では、AIツールとしてClaude Codeを使っています。試行錯誤の結果、対話を通じて思考を深めていくスタイルと、PythonスクリプトやAgent Skillsとの組み合わせが、自分の使い方として最もしっくりきました。

CLAUDE.md — AIへの指示書を構造化する

Claude CodeにはCLAUDE.mdという設定ファイルがあります。リポジトリのルートに置くだけで、セッション開始時にAIが自動的に読み込みます。

ここにITSAの全ルールを集約しています。

# CLAUDE.md の構成（抜粋）
## Role
あなたは戦略的思考パートナーです。
## Context Navigation（コンテキスト参照ガイド）
基本原則: タスクに必要なファイルだけを読む。
### タスク別参照マップ
- 戦略提案・ISS作成 → まず 03_strategy/README.md → 必要に応じて 01_identity/philosophy.md
- インシデント分析 → まず 02_telemetry/incidents/ → 必要に応じて 03_strategy/README.md
- 昇華判定 → まず 01_identity/discipline/ → 必要に応じて 03_strategy/
## インタラクション
- デビルズ・アドボケイト: 描かれた論理に反対の立場から批判的に検証し研磨
## Agent Skills
### /analyze-inbox  — Inbox層の課題を分析し、ITSAレイヤーへ振り分け
### /adr-propose    — 構造的課題・意思決定からADRを自動生成
### /action-status  — Action群の進捗を可視化
### /ascend         — 実行結果をIdentity層へ昇華すべきか判定

ポイントは4つです。

タスク別参照マップ。 AIが読むべきファイルを、タスクの種類に応じて定義します。「戦略提案ならまず03_strategy/README.md」「インシデント分析なら02_telemetry/incidents/」というように、タスク起点でコンテキストを絞り込む。全ファイルを毎回読ませるのではなく、必要なファイルだけを読ませることで、AIの応答精度と速度が上がります。

デビルズ・アドボケイト。 AIを受動的な整理役ではなく、あえて反対の立場から論理を批判的に検証するパートナーとして定義しています。リスクの有無にかかわらず、描かれた論理の不純物を除いて研磨する。この姿勢が「道具」ではなく「戦略パートナー」としてのAIを成立させます。

Agent Skills。 ITSAの運用サイクルをコマンド化しています。/analyze-inbox でInboxを分析し、/adr-propose でADRを自動生成し、/ascend で昇華判定を行う。Markdownファイルでスキルを定義すれば、AIが文脈を理解したうえで複数ステップの操作を自律的に実行できます。

MCP（Model Context Protocol）統合。 Slackなどの外部サービスと接続し、必要な情報をAI経由で取得できます。Telemetry層の事実収集を半自動化する基盤です。

canvas で計画し、作業リポジトリで実行する

ITSAモデルのもう一つの実践パターンとして、canvas（思考リポジトリ）と作業リポジトリの連携があります。

canvasで戦略を練り、Claude Codeに「この ADR に基づいて、作業リポジトリに ROADMAP.md と tasks.md を生成して」と指示します。すると、戦略の文脈を理解した上で、具体的なタスク分解とマイルストーンを含む実行計画が生成されます。

思考と実行を分離し、かつ一貫性を保つ。 canvasには「なぜやるか」が残り、作業リポジトリには「何をやるか」が残ります。両者をClaude Codeがつなぐことで、戦略と実装の乖離を防ぎます。

実際のワークフロー — ITSAサイクルをAIが回す

セクション4で紹介した障害対応シナリオを、Agent Skillsで回すとこうなります。

まず /analyze-inbox で障害報告を分析します。AIはTelemetryの過去パターンと照合し、「構造的課題の兆候がある。Strategy層で分析すべき」と振り分けを提案します。次に /adr-propose でADRのドラフトを自動生成。事実に基づいた構造的解決策の骨子が、数秒で手元に届きます。そして解決策が成果を上げた後、/ascend で昇華判定を行います。「この知見は3回以上再利用されたか？ 他のプロジェクトにも適用可能か？」— チェックリストに照らして、Identity層に定着させるべきか判定する。

ポイントは、このワークフロー全体が揮発しない構造の上で回っていることです。Telemetry層に事実が蓄積されているからAIはパターンを検知できる。ADRとして意思決定が構造化されているから、過去の判断と矛盾しない提案ができる。揮発しない構造があるからこそ、AIは「道具」ではなく「戦略パートナー」として機能するのです。

7. まとめ — 揮発の反対語は、蓄積である

知識は放っておけば揮発します。Slackに流れ、人の退職と共に消え、時間の経過で陳腐化する。

ITSAモデルは、この揮発に抗う「器」です。事実と解釈を分離し、意思決定の根拠を残し、実行結果を組織のDNAに昇華するサイクルを回す。揮発の反対語は「蓄積」であり、蓄積には構造が必要です。

知識は複利で効きます。今日書いた1つのADRが、来月の意思決定を加速します。今日記録した1つの障害パターンが、来年の同種障害を防ぎます。今日定義した1つの開発規律が、次の環境でもそのまま判断基準として機能します。そして蓄積された構造は、AIが組織の「戦略的思考パートナー」として機能するための基盤にもなります。

「育てれば育てるほど、ドキュメントが組織の知性になる」 — これが「AIと育てるマークダウン」の意味です。

余談ですが、思考活動にClaude Codeを取り入れてから、「もったいないからセッションあたりのトークンを使い切ろう」と欲が出ました。考えてみれば人間の思考にもトークンのような上限があって、「これはあとで考えよう」と後回しにしていた検討が実は多かった。AIに整理を任せると、コンテキストスイッチのコストという制約はあるものの、あらゆる検討を後回しにせず並列に進められるようになります。

マークダウンファイルを育てていきましょう。揮発させず、蓄積し、組織の知性に変えていきましょう。