技術チームが AI とどのように協働するかにおいて、静かな変化が起きています。
1 年前、世間の関心は「AI が PRD（製品要求仕様書）や RFC（コメント募集文書）、バグ報告の有用な初稿を書けるかどうか」にありました。
現在、その答えはすでに出ており、十分に書くことができます。
しかし、新しく浮上した問いはさらに困難なものです。「一人の人間ではレビューしきれないほどのドキュメントを AI が量産するようになった今、チームは一体どこで認識を合わせるべきなのか？」
コードの乖離（コードドリフト）はコードレビューでキャッチできます。スケジュールのズレはスタンドアップミーティングでキャッチできます。しかし、「ドキュメントの乖離（ドキュメントドリフト）」——つまり、AI アシスタントが生成したもの、エンジニアが実際に意図したもの、そして残りのチームが把握している状況の間に生じるギャップに対しては、これまで明確な答えがありませんでした。
中央に共有レイヤーがないと、AI が生成したドキュメントは作成された場所に放置されがちになります。誰かの Obsidian の保管庫（Vault）の中、Claude の会話の履歴、あるいはノート PC がスリープすると閉じてしまう Codex のセッションの中といった具合です。
私たちは様々なチームと、この課題をどう解決しているかについて話を進めてきましたが、その中でも特に印象的なエピソードがありました。ブロックチェーンのためのプライバシー保護インフラの最前線で活躍する HashCloak と Stoffel Labs の創設者、Mikerah Quintyne-Collins 氏です。彼女はチームのワークフローを詳しく説明してくれました。それは、2026 年における技術チームにとっての HackMD のあり方を明確に示す、非常に示唆に富んだ事例です。単なるエディタではなく、AI が生成した成果物とチームの認識共有を仲介する「ガバナンスレイヤー」としての活用法です。
変化：「どこで書くか」から「どこでチームが合意するか」へ
ほとんどのエンジニアは、個人用のドキュメントツールをすでに定めています。Mikerah 氏はローカルの保存先として Obsidian を使用しており、そこで大まかなアイデアをまとめ、Claude や Codex に送信するプロンプトを推敲し、共有する必要のない雑多な中間作業を保管しています。彼女のチームは毎日 AI コーディングツールと並行して作業しており、彼女は通常、CLI からその作業を動かしています。
その部分の課題は解決しています。解決していなかった、そして最終的に HackMD が埋めることになったのは、ある成果物が「個人の頭の中」から離れ、「チームが反応し、意見を戦わせ、それをベースに構築していくための共有資産」へと変わる瞬間です。
彼女はそのフローを、自身の言葉で次のように語ってくれました：
「現在の私のコーディング作業のフローは以下の通りです：
実装に必要な要件をまとめた、大まかな PRD を作成する。これは Obsidian で行い、その後にプロンプトを Claude や Codex にコピーする。
Claude や Codex に、この大まかな PRD を本物の PRD へと仕上げてもらう。
自分が本当に必要とする内容に合致するまで、PRD の調整を繰り返す。この段階で、内容をノートとして HackMD に投稿する。
PRD から RFC を生成する。RFC は、PRD を正常に実装するために必要な具体的な実装ディテールを提供する。
初期実装に必要な要件を満たすまで、RFC の調整を繰り返す。確定したら、これを HackMD の『ブック（Book mode）』として投稿し、メインの章で元の PRD ノートを参照させる。」
ここには、些細ながらも重要なパターンが隠されています。ドラフトの作成や推敲という重労働は AI が担い、Obsidian はローカルのスクラップ帳として機能します。しかし、成果物が「本物」になり、議論を交わし、レビューを受け、開発のベースラインとなる瞬間に、それは HackMD へと移行するのです。
この移行こそが、「ガバナンス（統治）」のステップです。
なぜ、特に HackMD へ移行するのか？
単に Markdown を Git にプッシュしたり、Obsidian のリンクを共有したり、他のドキュメントツールに貼り付けたりするのではなく、なぜ HackMD が最終目的地なのかを Mikerah 氏に尋ねたところ、その理由はいくつかの実用的な点に集約されました。
全員を Git に強制することなく、具体的かつ技術的な詳細を共有できる。
彼女のチームは、単なる実装結果だけでなく、機能の「根拠（ rationale ）」を理解する必要があります。HackMD を使えば、エンジニアが読みやすく、インラインでコメントを残し、プルリクエストを開くことなく返信できる形でその根拠を共有できます。彼女はこう語ります。「特定のコンポーネントの機能や根拠を、具体的かつ技術的な詳細とともにチームに共有しやすくなります。これにより、メンバーは自分たちのソフトウェア設計の意思決定を適切 方向付けることができ、私のアイデアに対しても簡単に意見をぶつけることができます。」
長期的で持続可能な知識。
PRD や RFC は使い捨ての資料ではありません。チームがなぜその選択をしたのかを記録した歴史です。Mikerah 氏は、このレイヤーを「ADR（アーキテクチャ意思決定記録）のようなもの」と表現しました。このように使用することで、HackMD のノートやブックは、初稿を生み出した AI セッションが終了した後も生き続ける「組織の記憶」となります。
規模に応じて拡張できる構造。
単一の PRD は 1 冊の HackMD ノートです。しかし、そこから派生する RFC を生成すると、小さなライブラリができあがります。HackMD のブックモード（Book mode）を使えば、それらの RFC を各章として整理し、元の PRD ノートを紐付けることができます。チームは、バラバラになったファイルのフォルダを見る代わりに、1 つの正統な入り口から、一貫性のあるデザインの全体像をスムーズに確認できるようになります。
下書きの先へ：過去を問い直すために HackMD を使う
今回の会話で最も興味深かったのは、新しいドキュメントを作成することではなく、「すでに 終わった作業」を理解するために HackMD を活用しているという点でした。
Mikerah 氏は、チームが日常的に使用している 2 つのパターンを挙げてくれました：
既存のコードや会話から設計根拠を逆引きする
彼女は AI モデルに既存のコードコンポーネントを読み込ませ、そこに組み込まれている設計上の意思決定を言語化させます。そして、それを HackMD に取り込んでチームでレビューします。また、スタンドアップミーティングや Slack のスレッドから生まれた、ドキュメント化されていなかった決定事項の根拠に対しても同じプロセスを行います。
「これにより、過去の決定を維持するか再検討するかの判断を迫られ、それをリリーススケジュールへと統合することができます。」
ギャップ（欠落）を見つけ出す
このように活用することで、HackMD は「存在するべきなのに存在しないもの」——欠落している根拠、レビューされていない前提、暗黙の了解になっていて明文化されていない仕様などを浮き彫りにする場所になります。
ここにこそ、「ガバナンス」という枠組みの本質があります。AI アシスタントは初稿を作成すること（すでに起きた作業の要約を含めて）において非常に優秀です。しかし、下書きがガバナンスとして機能し始めるのは、チームがそれを見て、議論し、コミットできる場所に置かれて初めて成り立ちます。その場所は、チャットウィンドウよりも永続的であり、Git レポジトリよりもアクセスしやすい場所である必要があります。
実務における変化
このワークフローによってチームにどのような改善がもたらされたか、Mikerah 氏に率直な答えを求めました。
彼女の回答は簡潔でした：
「文脈（コンテキスト）の紛失が減り、認識の一致（アライメント）が向上した。」
この言葉は深く吟味する価値があります。「開発スピードが 30% 向上した」というような、後付けでいくらでも作れる指標ではありません。「チームのメンバーが、お互いに何に、なぜ 取り組んでいるのか、そして何が決まったのかを把握している」という、より誠実な成果です。AI がドキュメントの「量」を生み出し、HackMD がその量を「解読可能」にするのです。
いま AI を活用しているすべてのチームにこれが重要な理由
Stoffel Labs は、設計上の意思決定が暗号技術やセキュリティに直接影響を与えるインフラを開発している、少数精鋭の技術主導型という特定のチーム形態を持っています。しかし、Mikerah 氏が説明するパターンは、多くのチームに共通して当てはまる普遍的なものです：
1. ローカルの AI 作業は高速に進む
エンジニアは Obsidian、Cursor、Claude、Codex、あるいはそれらの組み合わせを使用します。下書きの作成コストは非常に低いです。
2. チームの認識共有は簡単には進まない
「下書きがある」状態から「チームが方向性に合意する」状態までのギャップで、多くのプロジェクトが失速します。
3. 共有され、永続的で、コメントしやすいレイヤーこそが、そのギャップを埋める
それはチャットのスレッドではありません。
Git のレポジトリでもありません。
その中間に位置するものです。
Stoffel Labs にとって、HackMD はまさにその中間レイヤーです。ノートが PRD の正統なバージョンを捉え、ブックがそれに依存する RFC を整理します。コメントやインライン編集によって、チームは意見を交わすことができます。そして、初稿を生み出した AI セッションが閉じた後も、そのすべてが資産として残り続けます。
毎日 AI ツールを使っていて、ボトルネックが「書くこと」から「合意すること」へ移っていると感じているなら、Mikerah 氏が提示してくれたワークフローは試す価値が十分にあります。
あなたのチームでも試してみませんか
これを最も早く実感する方法は、チームが現在議論しているドキュメント（仕様書、バグ報告、アーキテクチャの提案など）を 1 つ選び、HackMD に移してみることです。
チームを招待し、インラインでコメントをもらい、何が見えてくるかを確認してみてください。
このフローの AI 連携をさらに強化したい場合、HackMD CLI や 開発者ポータル（Developer Portal） を使用することで、エンジニアや CLI 主導のワークフローを含め、チームが普段作業している場所から HackMD へ Markdown を直接シームレスにプッシュすることができます。