ブレインダンプからブログ記事へ

LLM を活用して学んだことをドキュメント化する方法

今日のスピード感あふれるソフトウェア開発の現場では、革新的なソリューションやベストプラクティスが、断片的なメモ、場当たり的なコミット、行き当たりばったりのトラブルシューティングに埋もれがちです。

私も多くの開発者と同じく、最初のブレインストーミングから最終的な解決策に至る全工程を記録するのは難題でした。ところが開発の各段階で LLM（Large Language Model）を使うようになってから、堅牢なシステムを構築するだけでなく、未整理のアイデアを分かりやすいドキュメントにまとめられることに気づいたんです。

こうして生まれたドキュメントは、あなた自身や チーム、組織、さらには コミュニティ全体 の学習を加速させる貴重なリソースになります。

本記事では、ここ数か月で練り上げてきたワークフローを紹介します。ただの「LLM でより良いコードを書くためのガイド」ではありません。これは 行動を促す呼びかけ です。ぜひあなた自身のプロセスを作り、洞察をドキュメント化し、共有してみてください。継続的に更新される知識ベースが生まれ、みんなで育てていけます。

LLM 活用ワークフローの概要

このワークフローは、次の 5 つのフェーズから成ります。

調査 / Researching — データの収集と統合
意思決定 / Deciding — 代替案の評価と方針策定
構築 / Building — AI ツールを使ったコーディング
反復 / Iterating — テスト・デバッグ・改善
文書化 / Documenting — 洞察と判断を整理しドキュメントにまとめる

もちろん、これらのステップそのものは目新しいわけではありません。Harper のような人たちは昔から似たプロセスで開発しています。

私が声を大にして伝えたいのは、最後の 文書化 までやり切り、得た知見を誰もが読めるハンドブックとして結晶させようという点です。

この反復的なワークフローによって、ドキュメント自体が常に更新される 生きた資料 となり、問題解決のあらゆる側面が循環して知識ベースを豊かにしていきます。

以下は、この継続的プロセスの高レベル図です。

  flowchart TD
    A[調査 / Researching] --> B[意思決定 / Deciding]
    B --> C[構築 / Building]
    C --> D[反復 / Iterating]
    D --> E[文書化 / Documenting]
    E --> F[共有学習リソース / Shared Learning Resource]
    F --> A

図: 各フェーズが次を後押ししながら循環し、最終的にコミュニティ全体に役立つリソースへとつながるサイクル。

調査 / Researching で LLM を使う

取り組みは調査から始まります。新機能や改修などに取り掛かったら、まずは漠然としたものも含めてアイデアを書き出しましょう。LLM をリサーチアシスタントとして使えば、的を絞った質問に対し要点をまとめた回答を返してくれます。無数のウェブページを手作業で探し回る代わりに、たとえば次のように尋ねてみます。

“What are the key differences between OAuth 2.0 and OpenID Connect for securing APIs? List pros, cons, and typical use cases.”
（API を保護する際の OAuth 2.0 と OpenID Connect の主な違いは？それぞれの利点・欠点・典型的なユースケースを列挙してください）

調査フェーズのベストプラクティス

具体的に質問する — 精度の高い情報を得るためクエリを絞る
フォローアップで深掘りする — 追加質問で理解を深める
重要情報は検証する — LLM の出力を起点に公式ドキュメントで必ず確認する
結果を要約してもらう — 知見が集まったら LLM に要約させ、後続フェーズの土台にする

Deciding（意思決定）：計画と設計

調査で得た情報をもとに、次は意思決定です。LLM を活用し、選択肢を比較し、トレードオフを評価し、高レベルの設計図を作成します。たとえばリアルタイム更新で WebSockets と HTTP ポーリングのどちらが適切か迷うなら、こう聞いてみましょう。

“Compare WebSockets and HTTP polling for a high-traffic chat application in terms of latency, scalability, and implementation complexity.”
（高トラフィックなチャットアプリで WebSockets と HTTP ポーリングを、レイテンシ・スケーラビリティ・実装の複雑さの観点で比較してください）

意思決定フェーズのベストプラクティス

詳細なコンテキストを共有する — プロジェクト要件や制約を明示
構造化された出力を求める — 箇条書きや表で比較を明確に
代替案を探る — 最初の答えに固執せず追加アプローチを質問
設計図を作る — 以降のコーディングを導くハイレベルな設計図を生成

このフェーズで得た設計図が、その後の作業指針になります。

構築 / Building で AI コーディングアシスタントを活かす

ここがまさに「魔法」の瞬間です。近年の AI ツールはコーディングのあり方を一変させました。VS Code に統合された GitHub Copilot も素晴らしいですが、Cursor や Cline といった専用エディタ、Vercel の V0 のようなサイトデザイナー、反復的な開発を支援する Claude Code なども登場しています。さらに複数モデルを統合できる高度な Aider まであります。

この記事は 2025 年第 1 四半期末に執筆されました。読む時期によっては、ここに挙げたツールの競合が 10 個以上現れ、今は想像できないツールも登場しているかもしれません。

編注（2025 年 4 月中旬）: すでに Continue 1.0、Abacus.AI、そして OpenAI の新しいコーディング向けモデルなど、多くの選択肢が追加されています。

コーディングで AI を活用する方法

タスクを小分けにする — アプリ全体を丸投げせず、扱いやすいコード片を依頼する
プロジェクトも小さく保つ — プロジェクト自体もスリムにし、独立したモジュールの組み合わせとして設計する
コンテキストを提供する — 関連コードや設定を示して精度を上げる
反復して磨く — AI 生成コードは下書きと捉え、テスト・レビュー・再質問を繰り返す
専門ツールを試す — 自分のワークフローに合うプラットフォームを探る
厳格なルールを設ける — linter を厳密に設定し、Python のように型チェックがオプションの言語では必ず有効化する。JavaScript なら TypeScript を使おう
包括的にテストする — あらゆるケースを網羅すること。LLM がテストで“抜け道”を使わないか監視しよう。とはいえ大半は定型作業なのでどんどん任せて OK

反復 / Iterating：テスト・デバッグ・改善

コードが一発で動くことはまずありません。イテレーションこそが開発の要です。ビルド後にエラーや性能問題に遭遇したら、問題の詳細とコード片を LLM に提示して助けをもらいましょう。

  flowchart TD
    A[コードを書く / Write Code] --> B[テストを実行 / Test Code]
    B --> C{テストは通った？ / Do tests pass?}
    C -- YES --> D[デプロイ・文書化 / Deploy & Document]
    C -- NO --> E[LLM でデバッグ / Consult LLM for Debugging]
    E --> A

図: コード作成・テスト・デバッグを AI と回すループ。

反復フェーズのベストプラクティス

問題を切り分ける — エラーやボトルネックを一つずつ解決
コンテキストを渡す — 関連コードやエラーログを含めて質問
理由を尋ねる — 修正案だけでなく根拠も求める
再テストする — 修正が問題を解決し、副作用がないか確認する

このループを回すことで、最終的なソリューションは堅牢かつ効率的になります。

文書化 / Documenting：包括的な学習リソースを作る

ここで全てが結晶し、次のプロジェクトへの推進力になります。

最後のフェーズでは、調査・設計図・コード・デバッグの知見を集め、磨き上げたドキュメントを作成します。ただの説明書ではなく、問題解決の全ストーリーを語るリソースです。

ドキュメントは無いよりあったほうが良い——とはいえ、本当に優れたドキュメントはシステムの仕組み以上のことを語ります。まず「どんな課題を解こうとしたか」を明確にし、検討した選択肢と採用・却下の理由を示し、結果として得たソリューションとその働きを解説します。類似プロジェクトや参考資料へのリンクがあるとなお親切ですね。

  flowchart TD
    A[下書きを作成 / Draft Documentation] --> B[LLM レビュー／提案 / LLM Review & Suggestions]
    B --> C[開発者が推敲 / Developer Edits & Refinement]
    C --> D[完成版ドキュメント / Final, Polished Document]

図: AI が作成した下書きを人間が磨き、最終ドキュメントへ仕上げるサイクル。

文書化フェーズのベストプラクティス

段階的に書く — 各フェーズが終わるごとに追記する
LLM に要約させる — 生のメモを読みやすい構造化テキストに変換
徹底的にレビューする — 技術的正確さと読みやすさを確認
広く共有する — ブログや社内 Wiki、コミュニティに公開しフィードバックを募る

完成したドキュメントはケーススタディとなり、思考過程・トレードオフ・最終解決策を凝縮したリソースです。読む人は学習を加速でき、コミュニティ全体の財産になります。

もし Deep Research 機能を持つモデルがあれば、完成記事を投入して関連リソースや関連記事を自動収集し、リンクを追加することも可能です。

Harper の LLM コード生成ワークフローから学ぶ

この手法を試していたのは私だけではありません。友人の Harper も LLM を使って小さなプロダクトを次々に作り、そのプロセスをブログ記事「My LLM Codegen Workflow (ATM)」で共有しています。彼はこう語ります。

“I have been building so many small products using LLMs. It has been fun, and useful. However, there are pitfalls that can waste so much time. A while back a friend asked me how I was using LLMs to write software. I thought ‘oh boy. how much time do you have!’ and thus this post.”
（LLM を使って小さなプロダクトを山ほど作ってきたよ。楽しいし役に立つけど、時間を無駄にする落とし穴も多い。少し前に友達から「どうやって LLM でコード書いてるの？」って聞かれてさ――いやはや、どれだけ時間ある？ってことでこの記事を書いたんだ。）

さらに彼はこう付け加えています。

“This is working well NOW, it will probably not work in 2 weeks, or it will work twice as well. ¯\(ツ)/¯”
（今はうまくいってるけど、2 週間後には通用しないか、もしくは 2 倍うまくいくかのどっちかだね。¯\(ツ)/¯）

これらの言葉は、プロセスが動的であり、ツールの進化や学びによって常に変わることを思い出させてくれます。ぜひ彼の記事も読んでみてください。

まとめ

このワークフローの真の力は、散漫で未整理な旅を、学習を加速させる明確で構造化されたリソースに変える点にあります。LLM を使って 調査 → 意思決定 → 構築 → 反復 → 文書化 を回すことで、ソリューションを深く理解しつつ、他の人にとっても役立つガイドを作り出せます。

さあ、あなたのプロジェクトでもこの LLM ベースのワークフローを試してみませんか？

実験する — 開発のあらゆるフェーズに LLM を組み込んでみましょう
文書化する — 生のアウトプットを磨き上げ、ブログや技術ドキュメントにまとめてみましょう
共有する — 成果を公開し、洞察を共有し、フィードバックをもらいましょう
反復する — プロセスを継続的に改善し、その改善も記録しましょう

これにより、生産性が上がるだけでなく、誰もが学べるライブラリを構築できます。

開発の旅をしっかり記録すれば、自分の成長スピードも上がり、周囲も速く進めます。ツールを使い倒し、プロセスを共有し、コミュニティをともに強くしていきましょう。