ブログとADRの相乗効果：AI 時代のナレッジサイクル

「死んだドキュメント」という負債からの脱却

開発の意思決定を記録する ADR（Architecture Decision Record）も、本来は非常に重要なものです。しかし、正直に言えば、今までは ADR を積極的に残してきませんでした。

その理由は、多くのエンジニアが共感してくれるであろう「ドキュメントの形骸化」にあります。「残しても後から情報を参照するのがとても手間で、誰かに聞きに行ったほうが圧倒的に早かった」。これが現実でした。検索してもヒットしない、ヒットしても文脈がわからない。そんな「死んだドキュメント」を書くために時間を使うのは、開発者にとって苦痛でしかありません。また XP（アジャイル）で開発しており、「包括的なドキュメントよりも動くソフトウェアを」を免罪符にして、ドキュメントを後回しにしてきたという背景もあります。

以下の記事でも同様のことが指摘されています。非常に共感できる内容です。

https://note.com/tandago/n/n53a07a09b414

最初に挙げた「アジャイルはドキュメント書かない」派の方々はこれを読み違えている可能性がありまして、確かに「動くソフトウェア」優先なのですが、あくまで「優先」であり、「書かない」もしくは「書かなくても良い」等とは書いていません。あくまで優先の問題なのです。

https://objectclub.jp/technicaldoc/xp/agile_misunderstanding#q3

もちろんアジャイルプロセスでもドキュメントは書きます。ただ優先順位が異なるだけです。『アジャイルソフトウェア開発宣言』にもあるように「完全なドキュメントよりも、動くソフトウェア」を相対的に重視するだけです。「コードがドキュメントだ」とうそぶくことは簡単ですが、「ドキュメントであるかのようなコード」「ドキュメントが不要なコード」を書くのはとても難しいです。また、コードだけでは「なぜこの設計にしたのか」「なぜ他の設計にしなかったのか」という設計判断の根拠が残せません。

昨今では AI を活用することで、ADR を残すことに大きな価値が生まれてきました。特に NotebookLM のようなツールが、ドキュメントの価値を劇的に高めてくれています。生成 AI の登場によって、ドキュメントは「書いても読まれないもの」から「AI に聞けば即座に答えてくれる生きた知識」へと変わりました。これにより、ドキュメントを書くことの価値が一気に高まり、積極的に残すようになりました。

NotebookLM がドキュメントに命を吹き込んだ

私の所属している会社では NotebookLM を活用しています。これによって、コードからは読み取れない「なぜその時、この技術を選んだのか？」「どのようなトレードオフを検討したのか？」という背景を、AI に聞くだけで即座に引き出せるようになりました。

今まで形骸化していたドキュメントが、AI という「全知の司書」を介することで、瞬時に価値ある回答をくれる「生きた知識」へと変わったのです。これを最大化するために、チームでは以下の運用を徹底しています。

徹底的な情報の集約: 全ての内容は Google Docs やスプレッドシートにまとめ、振り返りのレトロ（KPT）や重要な会議は全て Google Meet で文字起こしと動画をセットで残します。
NotebookLM の日常化: よく使う Slack チャンネルのトップに NotebookLM のリンクをピン留めし、「この仕様、なんでしたっけ？」という会話が出たら、まず「NotebookLM に聞いた？」と確認し合います。

ADR で全てを残すことができるわけではありません。例えば、会議の中での雑談や、ふとしたアイデアなどは、ドキュメントに残すほどの内容ではないかもしれません。会議やレトロを文字起こしして残すのは、あくまで文書化されていない情報を拾うためで、全ての情報を残したいからです。デイリーチェックインは動画は撮らずに文字の情報としてのみ Docs に書いています。NotebookLM に与えられる情報にも限りがあり、デイリーチェックに関しては、ライトな話し合いのみなので残さないようにしています。

そのドキュメントを書く際に意識していることは「結論を残すこと」です。議題や背景だけを書いておくと、後から見返した時にどうなったかがわからなくなってしまうため、結論も必ず残すようにしています。そうすることで動画を見返す必要なく、ドキュメントだけで完結させることができます。

また、人が読むための「最新の仕様書」を常にメンテナンスし続けるのは、正直に言って大変な作業です。開発の現場では、Figma のデザインやソースコードを眺めていても「結局、最新の仕様はどれだっけ？」と迷うことが多々あります。この時、最新の仕様書がないと、NotebookLM は過去の意思決定（ADR）のみを参照することになります。しかし、ADR が全ての情報を完璧に拾えているわけではないので、どうしても情報は抜け落ちてしまいます。

だからこそ、仕様が決まった瞬間に仕様書へたった一文だけでも「最新の仕様」を書き加えておくことが非常に重要です。この最小限のメンテナンスがあるだけで、NotebookLM は過去の経緯と現在の正解を繋ぎ合わせ、正確な回答を返せるようになります。たった一行の更新が、AI の回答精度を劇的に高め、チームの迷いをゼロにするための鍵になるのです。

そして、「まず AI に聞く」という文化をチーム内で決めることで、AI の情報源となるドキュメントをメンテナンスしようという意識が、誰に言われるでもなく自然と湧いてくるようになりました。ドキュメントを書くことが「義務」ではなく「自分たちの効率を上げる投資」に変わった瞬間です。

ADR とブログ執筆の戦略的シナジー

ADR を細かく残すようになり、私はもう一つの大きなメリットに気づきました。それは、**「ADR を書くために色々調べる作業が、ブログを書くためのリサーチと重なる」**ということです。

ブログ執筆を「ADR のついで」にする

私は元々、自分のブログを書いているくらいにはアウトプットへの意欲がありましたが、それでも会社での執筆は「年に 1 本出せればいいか」という重い腰を上げる作業でした。それが、今は月に 2 本ペースで書くことができています。

その秘訣は、ADR をそのままブログのドラフト（下書き）として引用する手法にあります。ブログとして構成を一から考え直す必要はありません。ADR に書いた「背景」「検討した代替案」「決定した理由」が、そのまま記事の骨子になります。

「調査時間」を「資産を増やす時間」へ変える

技術選定やバグの調査は、時に孤独で苦痛な作業です。しかし、ADR を書くことを前提にすると、その調査の時間は「消費される時間」から「チームの資産を増やす時間」へと変わります。

自分が苦労して調べたことが、単なるメモリ上の記憶で終わらず、ADR という資産になり、さらにブログとして公開される。自分の苦労が「誰かのためになる」という実感が、調査の苦痛を和らげ、モチベーションへと変えてくれます。

チームで調べるから、一人より遥かに効率的

また、ここには社内プロジェクトならではの大きな利点があります。個人のブログであれば、調査はすべて自分一人で完結させなければなりません。しかし、会社の ADR の場合は違います。

ADR はチーム内でレビューされます。自分が下調べした内容に対して、他のメンバーが「こんな手法もあるよ」「この観点は抜けていない？」と知見を出し合ってくれます。つまり、一人でブログのためだけに調べるよりも、チームを巻き込んで ADR を作るほうが遥かに効率的で、かつ情報の正確性も高まるのです。この「共同リサーチ」の結果をそのままブログに引用できる。これほど贅沢で効率的なアウトプットの仕組みはありません。

質よりも「量」と「コンテキスト」を優先する

「会社で出すブログなら、高い質を担保しなければ」という思い込みが執筆のブレーキになります。しかし、私は**「量は質に転化する」**と信じています。

こと ADR をブログに変換してアウトプットすることに関しては、洗練された文章術よりも**「その状況下で、なぜその選択をしたか」というコンテキスト（意思決定）**を出すことに価値があります。このアウトプットを「量」として継続していくために、以下のハックを活用しています。

情報のぼかし（安全性）: 公開できない情報は、自分で情報をぼかして書くか、AI に「機密情報を除外して一般論に書き換えて」と指示します。これにより、セキュリティの不安で筆が止まるのを防ぎます。
AI のプリレビュー（効率化）: 会社独自の執筆ルールや過去の自分のブログを読み込ませた AI に、まずはレビューをさせます。文体や口調を整えるのは AI に任せ、自分は「内容の正確性」や「コンテキストの記述」に集中します。

たとえそれが「100% の質」ではなくても、ある程度の質で誰かに届けることが、結果的には価値に繋がります。完璧な記事を目指すよりも、**「今の自分が伝えられるベストな内容を、できるだけ早く届ける」**ことを優先するべきです。ブログを読む時に読者が求めているのは、過度な装飾ではなく実体験に基づいた情報だからです。

新規事業における「決断」の共有：EAS の事例

ブログを社内メンバーでレビューしていますが、そこで指摘された内容があれば、さらに深掘りをして社内の ADR に反映させる。このサイクルこそが、ADR や仕様書をさらに洗練させます。

現在、私は新規事業を開発しており、ここでは「100% の質」よりも「ある程度の落とし所を決めて前進する意思決定」が求められます。例えば、モバイルアプリの E2E テスト導入において、私たちは大きな方針転換をしました。

以前のプロジェクトでは、自分たちでコンテナ環境を構築し、完全にコントロール可能な環境でテストを行うのが通例でした。しかし今回は、自分たちでの環境構築を一切やめ、EAS（Expo Application Services）をそのまま使うことにしました。

理由は明確です。新規事業という不確実なフェーズにおいて、環境構築のメンテナンスにリソースを割くよりも、お金を払ってでも素早くリリースし、市場の反応を見るべきだと判断したからです。このような「学び」や「あきらめたこと（トレードオフ）」をブログで共有すること。それは単なる技術紹介ではなく、ビジネスと技術の交差点におけるリアルな意思決定の共有です。

まとめ：ナレッジサイクルを回し続ける

ADR を細かく書き、それを AI の力でブログへと昇華させる。この仕組みに気づいてから、アウトプットの苦しみは消え、発見の楽しさが勝るようになりました。本当に意識が変わっていったことを実感しています。「これは ADR に残しながらブログも書くかー」という感じで、自然と両方を意識するようになりました。

現場のリアルな意思決定を ADR に刻む（調査コストを資産に変える）
AI（NotebookLM）でチームの知識を自動化する
そのままブログ化して外部へ共有し、得られた知見を現場へ還元する

このADR とブログの相乗効果によって、ナレッジサイクルが高速で回るようになりました。これからもこのサイクルを回し続け、技術的な学びをどんどんアウトプットしていきたいと思います。