第一章:人 × 複数AI の協働フロー — 1記事目はこうして作られた
この記事について
このブログ記事は、1記事目の作成プロセスを記録した
AI対話ログ(8 files、約 124 KB)をもとに、
ChatGPT / Claude Code が再構成・編集したものです。
1記事目で「docs × AI による開発記録」というコンセプトを紹介しましたが、
この記事では、その1記事目が実際にどう作られたかを公開します。
はじめに
前回の記事「docs × AI による開発記録 – このプロジェクトのコンセプト」では、
AIを「整理役・編集者・パートナー」として位置づけ、
docs を中心とした開発記録の考え方を紹介しました。
今回は、その記事がどのように作られたかを、
実際のフローと各AIの役割分担を通じて見ていきます。
なぜこの記事を書くのか。
それは、「AIと一緒に記事を作る」という言葉だけでは、
実際の手順や判断の流れが見えにくいからです。
この記事では:
- どのAIを、どの場面で使ったか
- 各AIとどんなやり取りをしたか
- すべての対話をどう記録として残したか
を、1記事目の作成過程を例に説明します。
登場人物(役割分担)
1記事目の作成には、私と4つのAIが関わりました。
私(開発者)
- 最終判断と責任
- 方向性の決定
- レビューと修正指示
- 各AIへの指示出し
ChatGPT
- コンセプト整理・思考の壁打ち
- ADR(Architecture Decision Record)の説明
- ブログコンセプトの言語化
- 記事の添削・レビュー
- 次回記事の企画立案
Claude Code
- docs からの記事生成
- 初稿作成
- GitHub PR コメントへの対応
- 技術的な編集作業(見出しレベル調整、表現統一など)
Zenn AI
- 投稿前レビュー
- プラットフォーム固有の推奨事項(見出しレベル、水平線)
- アクセシビリティ観点のチェック
Google Gemini
- 公開後レビュー
- 第三者視点からの評価
- 次回記事への改善提案
それぞれが異なる役割を持ち、
私が各AIに適切なタイミングで指示を出すことで、
記事が少しずつ形になっていきました。
実際のフロー(1記事目の作成過程)
1記事目がどのように作られたかを時系列で追ってみます。
全体で7つのフェーズを経て、1記事目が完成しました。
各フェーズの詳細
Phase 1: コンセプト整理(ChatGPT)
きっかけ: 「設計のレビューを可視化する開発手法って何だっけ?」
ChatGPT に質問したところ、ADR(Architecture Decision Record)という手法を教えてもらいました。
そこから、自分の開発スタイルがADRに近いことに気づき、
ブログのコンセプトを「docs × AI」として整理していきました。
このフェーズで重要な方針決定をしました。
ブログでは、アプリケーションの具体的な内容ではなく、
docs を元に AI が記事を書く体裁でいくという方向性です。
現時点では、ブログの内容は設計思想の記録や可視化を中心としており、
その整理先としてのブログという形を取っています。
成果物: docs/sandbox/day3.3.chatgpt.txt(30KB)
Phase 2: 初稿作成(Claude Code)
指示内容: 「docs をもとに、ブログ記事を作成してください」
Claude Code は docs に残していた内容を整理し、
Zennの記事形式で初稿を生成してくれました。
成果物: 20251228.zenn.dev.contents.md
Phase 3: レビュー(私)
GitHub で PR を作成し、記事をレビューしました。
主な指摘内容:
- 不要なセクション削除
- ADR参照リンクの追加
Claude Code が全修正を反映してくれました。
Phase 4: 添削(ChatGPT)
ChatGPT の評価:
- 「このまま publish して問題なし」
- コンセプト・運用・記事が完全に一致
指摘点:
- 「判断主体は人間」という軸が後半やや薄れる
対応:
- 「ただし、最終的な判断と責任は、私にあります。」を追加
成果物: docs/sandbox/day3.4.chatgpt.txt
Phase 5: 投稿前レビュー(Zenn AI)
Zenn のプレビュー画面でレビューを依頼しました。
Zenn AI の評価:
- 「深い洞察と実践が詰まった、非常に興味深い記事」
- 技術的に正確で、誤字脱字なし
指摘点:
- 見出しレベルを
##から始める(アクセシビリティ推奨) - 水平線(
---)の使用を最小限に
対応:
- Claude Code が
#→##、不要な---を削除
成果物: docs/sandbox/day3.5.zenn.txt, day3.6.zenn.txt
Phase 6: 公開
最終調整として、個人を示す表現を全て「私」に統一し、
Zenn で記事を公開しました。
Phase 7: 公開後レビュー(Gemini)
公開後、Google Gemini にも読んでもらいました。
Gemini の評価:
- 「開発プロセスの新しいスタンダードを感じる内容」
- Before/After のチラ見せ、プロンプトのヒントなど次回への改善提案
成果物: docs/sandbox/day3.7.gemini.txt
各AIの使い分け基準
実際の作業を通じて、各AIの使い分けが自然と定まってきました。
ChatGPT を使うとき
-
コンセプト整理・思考の壁打ち
- 「これって何だっけ?」という質問
- 考えを言語化する手伝い
-
長文レビュー・添削
- 記事全体を読んでフィードバック
-
企画立案
- 「次は何を書こうか」の相談
Claude Code を使うとき
-
docs からの記事生成
- 既存の docs を元に文章を構成
-
具体的な編集作業
- 見出しレベル調整、表現統一など
-
ファイル操作を伴う作業
- 複数ファイルの編集、git 操作
Zenn AI を使うとき
-
プラットフォーム固有のチェック
- Zenn の推奨スタイル確認
-
投稿前の最終確認
- アクセシビリティ、見た目の確認
Gemini を使うとき
-
第三者視点のフィードバック
- 公開後の振り返り
- 他のAIとは異なる視点
記録の残し方
すべての対話を docs/sandbox/ にファイルとして保存しています。
docs/sandbox/
├── day3.3.chatgpt.txt - ChatGPT コンセプト整理
├── day3.4.chatgpt.txt - ChatGPT レビュー
├── day3.5.zenn.txt - Zenn AI レビュー
├── day3.6.zenn.txt - Zenn AI 細かい指摘
└── day3.7.gemini.txt - Gemini レビュー
なぜファイル化するのか
1. 次回以降、AIに文脈を引き継げる
対話をファイルで残しておくと、
別のセッションで Claude Code に「docs/sandbox/day3.4.chatgpt.txt を読んで」と指示できます。
毎回ゼロから説明し直す必要がありません。
2. 判断の履歴として残る
「なぜこの表現にしたか」「何を削除したか」が、
後から振り返れます。
3. ブログ記事の素材になる
この記事自体が、保存した対話ログをもとに作られています。
記録していたものが、そのまま次の記事になります。
このフローのメリット
実際にこの方法で記事を作ってみて、感じたメリットは以下の通りです。
1. 各AIの強みを活かせる
ChatGPT は長文の整理が得意、
Claude Code はファイル操作が得意、
Zenn AI はプラットフォーム固有の知識がある。
それぞれの強みを適材適所で使うことで、
1人では到達しにくい品質に近づけます。
2. 判断の透明性が保たれる
すべてのフェーズで「誰が」「何を」「なぜ」判断したかが記録されます。
最終判断は必ず私が行い、
AIは提案役・整理役に徹する、という構造が維持されます。
3. 再現可能
このフローは特別なツールや環境を必要としません。
- Mac 1台
- Terminal / Git / GitHub
- ChatGPT / Claude Code / Zenn AI / Gemini
誰でも同じ手順を踏めば、同じような記事作成プロセスを試せます。
ただし、現時点では各AI間の情報のやり取りは、
コピー&ペーストなどを利用してテキストレベルで行っているため、
少し煩雑な手順になっています。
この点は改善の余地がありそうです。
4. 記録が自然に溜まる
対話をファイル化する習慣があれば、
意識せずとも「開発の履歴」が残ります。
それが後から記事の素材になり、
振り返りの材料にもなります。
おわりに
この記事では、1記事目がどのように作られたかを、
7つのフェーズと4つのAIを通じて紹介しました。
このフローは完成形ではありません。
次の記事を書くときには、また違う進め方になるかもしれません。
ただ、今の時点では:
- 各AIの役割が明確
- 判断の流れが記録される
- 再現可能な手順になっている
という点で、私にとっては十分に機能しています。
次回は、この開発記録がどのようなディレクトリ構成で管理されているか、
docs/ の中身をもう少し詳しく見ていこうと思います。
上演目録(docs × AI による開発記録)
※本シリーズでは、試行錯誤のプロセスを「上演」に見立て、進行単位を「幕」として記述します。
第一部:docs × AI(全五章)
- 序章:docs × AI による開発記録 – このプロジェクトのコンセプト
- 第一章:人 × 複数AI の協働フロー — 1記事目はこうして作られた
- 第二章:internal-first — GitHub事故を防ぐための(local.gitという)舞台設計
- 第三章:docs の全体像 — 舞台装置としての構造
- 第四章:docs をどう使っているか — 運用と循環
第二部:対話ログの整理(全六幕 + 幕間)
- 第一幕:ローカルSLMで対話ログを要約する — 動機・アーキテクチャ・最初の壁
- 第二幕:前処理で80%削減 — コードブロックと識別子の扱い
- 第三幕:Multi-Passカテゴリ抽出とチャンクサイズの最適化
- 第四幕:カテゴリ設計の失敗 — 増やせば良くなるという幻想
- 第五幕:測定と収束 — Eval-Kit とカテゴリ統合
- 幕間:5つの幕で得た学びと失敗
- 第六幕:GroupReduce — パイプラインの再利用で新しい問題を解く
作成日: 2026-01-04
ステータス: 公開
生成元: docs/sandbox/day3.*.txt(8ファイル), AI対話ログ
記事作成プロセス
- 初期作成: Claude Code v2.0.76
-
構成企画: ChatGPT v5.2(
docs/sandbox/day3.8.chatgpt.txt) - 初回レビュー: 私
- 添削予定: ChatGPT v5.2
- 投稿前レビュー: Zenn AI
- 投稿後レビュー: Google Gemini
※ この記事は、1記事目の作成過程を記録した AI対話ログをもとに Claude Code が整理・再構成しました。
Discussion