Claude Codeで仕様設計は爆速になったけど、結局、調整に時間がかかる問題をどうするのか

Claude Codeで仕様書を書くようになって、初稿の作成時間は劇的に短くなりました。

しかしながら、運用してみると、リリースまでのリードタイム全体はほとんど変わっていないことに気づきました。

今回は、「初稿は速くなったのにリードタイムが減らない」現象がなぜ起きるのか、自分の現場での観察をもとに整理してみます。

体感は爆速、でも実は遅い

正直、具体値を測っているわけではないんですが、

「仕様作成までは、爆速でおわる、仕様調整に時間がかかる」

といった実感があります。

↓イメージ

「AIで爆速になった！」という体感はあるんですが、それは初稿フェーズの話だけだったんですよね。

AIの品質はこれからも上がっていくと思いますが、それは初稿フェーズをさらに効率化するだけ。合意形成フェーズに手を入れない限りリードタイム全体は変わりません。むしろ初稿が速くなるほど、合意形成の比重がボトルネックとして目立ってきます。

原因は2つあった

リードタイムが減らない理由は、2つに整理できました。

① 意思決定が二重に走るフロー構造

レビューの意思決定が二重化されていて、両方の合意を取らないと前に進めない、というやつです。

（大き目の企業あるあるですね）

多くの組織で同じはずで、純粋なエンジニアリングの速さでは削れない領域なので、今回は深追いしません。

できる限り、フィードバックから修正のループを回すことを主題として話します

② レビューフォーマットの不一致 ← 今回の本題のため大切

これが地味だけど致命的でした。

• AIが書くフォーマット = Markdow（git差分が取れて、Claude Codeが直接編集できる、AI親和的）
• 既存の意思決定フォーマット = Excel（AIが直接触れない、非AI親和的）

このフォーマットの違いが、二重構造をボトルネックに変えてしまっていました。

「最初のレビューはMarkdownで完結できるはず」なのに...

初期レビューだけならMarkdownで完結できるはず、それなのに、なぜか毎回Excelに変換している運用が多い。

なぜか。答えはシンプルで、下流のレビューフォーマットがExcelで固定されているからです。どうせ最終的にExcel化するなら最初から変換しよう、という運用が定着してしまっているんじゃないかと思います...

つまり、エクセルに変換することが前提になっていること自体が、上流のAI親和性まで殺している構造でした。下流のフォーマットが、上流のワークフロー全体を規定してしまっています。

問題は、ワークフローの設計 そのものにあります。

症状：Excel への片方向変換問題

このフォーマット不一致が具体的に何を引き起こすか。
「片方向変換問題のつらみ」とこの記事の中では定義しましょうか。

↓ Markdown → Excel 片方向変換問題のつらみ 

流れはこんな感じです。

1. Claude Codeで仕様書をMarkdownで書く
2. 下流に渡すために、Excelに変換する
3. Excel上で内部レビューも下流レビューも全部やる
4. Excel上で手書きで修正する
5. 気がつくと、Excelが事実上の最新版になっている

問題は、Excel上の手動修正をMarkdownに戻す方法がない（あるいは超面倒）ということ。セルに書き込まれたメモを、関連セルとの整合性を取りながら構造化されたMarkdownに反映するなんて、やってられません...

結果として、改修ループからAIが外れます。せっかくClaude Codeで書いたmdは古いまま放置されて、次の改修サイクルも結局Excel上で手動でやることに。

つまり、AIで初稿を作るメリットが 「初稿の1回しか効かない」構造になってしまっていたんですね。これがリードタイムを減らせない本当の理由でした。

↓ 合意形成の時間は変わってない,,,

理想のループを定義してみる

じゃあどうあるべきか。理想のループを定義してみます。

↓ AIもレビュアーも1つループに納めたい

4ステップで完結する形です。

1. AIで生成・修正する：Claude CodeでMarkdownのまま書く
2. レビュアーにシームレスに共有する：Excelに変換せず、Markdownのまま読める形で
3. レビュアーがコメントを返す：理想は直接編集も可能
4. AIがコメントを取り込んで反映する：Markdownの上で完結する

そして1に戻る、というループです。

ここで決定的に大事なのは、正本はずっとMarkdown（git）であり続けるということ。図のとおり、一度もExcelに転記しません。

この前提が崩れた瞬間に、さっきの「片方向変換問題」に戻ってしまいます。Markdownを正本として保ち続けることが、AI改修ループを生かすための必要条件です。

「これって理想論じゃないですか？」と思う方もいるかもしれませんが、実装手段はこのあと詳細を詰めていきます。

ループを実現する3つの優先度

理想のループを実現するための要件を、3つの優先度に分解してみました。

優先度1：Markdownに寄せる

これは譲れない最初の制約です。

Claude Code(AIエージェント)が直接触れる形式じゃないと、改修ループにAIを組み込めない。
逆にこれさえ満たせれば、ツールは後から選び直せます。

これを諦めると「初稿だけAI、残り全部手動」の現状から抜け出せないので、これが一番重要です。

優先度2：レビュアーにシームレスに共有 + コメントしてもらう

これを満たさないと、共有のたびにExcel化が発生してしまいます。

機能要件はざっくり3つ。

• MarkdownとMermaid図がきれいに表示できる
• ページ単位 or ブロック単位でコメントできる
• 理想的にはインラインコメント（行単位の指摘）も可能

ここが本記事の本丸です。

実現方法としては、

• 表示だけなら、静的サイトジェネレータでいけますね。Docusaurusを使えば見た目も整います。
• コメント機能は、BackLogのAPIやMCPで自動で転記して、そこでフィードバックしてもらうことがいいでしょうか。

※社内のセキュリティー上、IPを制限した上で、社内公開する必要や特定のSassに頼らないといけないこともあるはず

優先度3：レビュアー側が直接編集できる

これが一番難しい優先度です。コメントを返してもらうだけでなく、軽い文言修正はレビュアー側で直接やってもらいたい、というケース。

満たそうとすると、双方向 git sync (自動同期) ができる仕組みが必要になります。Web UIで編集 → 自動でgitに反映、という流れ。

具体的にはGitBook級の有料ドキュメント管理ツールが該当します。企業単位で導入すると、月額数百ドル規模の大きさにはなってしまいますが...（ https://www.gitbook.com/ ）

全部満たさなくていい

ここで大事なのは、3つを全部満たさなくていいということ。

• 1(マークダウン正本)だけで十分 → 今のGitHubで終わる（無料）
• 2(共有とコメント)まで必要 → 静的サイト + BackLog等に手動アップロード（低コスト）
• 3(双方向修正と同期)まで必要 → 有料の専用ツール（要投資）

組織の現状と必要度に応じて、どこまで満たすかを決めればOKです。すべての組織が3を目指す必要はないと思っています。

問題解決のための個人的結論

2までを綺麗に再現するとなっても、
GitHubのシームレスな連携 + コメント機能 + アクセス制限 の機能を持ったサービスはなさそうでした…

唯一対応できる、gitbookはめちゃくちゃ高いです…
(小規模のチームでも、全員に権限を付与するとなると、年に数十万はかかりそうでした...)

それなら実装してしまえばよいのではないか、といった気持ちにはなっています。
以前であれば、これだけでお金をとれるようなサービスだったかと思いますが、このくらいの要件ならギリギリ内製できそうですかね 

↓cluadeにデザインしてみてもらいました

まとめ

今回伝えたかったこととしては、2点です。

① ツールが現在のAIを組み込んだフローに対応できているのかを考える

現状、意思決定フローにおいて、AIの良さがなくなっている可能性があります。
あらためて、現在のプロジェクトの意思決定構造や、設計フローを見直す必要があると考えています。

また、理想を定義した上で、社内で使えるならどの課題まで改善するか、ということをあらためて考えてみると面白いかもしれません。

② 最も守るべきは「正本がMarkdownであり続けること」

これさえ守れれば、ツールはいつでも乗り換えられます。逆にこれを諦めると、AI改修ループが切れて、初稿の速さしか享受できない世界線に戻ります。

そしてMarkdown正本化は、レビュアー側にとっても「最新版がどれか分からない」「Excelに散らばったコメントを追えない」みたいな問題が消えるので、関係者全員にとってメリットのある話だと思っています。

AI時代のドキュメント問題は、ツール選定の話ではなく、正本のフォーマットをどう守るか、今の組織の中で、開発フローをどう設計するかを根本的に考えなすことが大切だと思いました。