同じ手順を2本目に適用したら何が変わったか｜並列エージェントで22章145,000字【AI活用検証vol.90】

1本目でうまくいった手順は、2本目でどこまで速くなるのか。この検証は、その確認でもありました。

前回と同じ手順でVercelの公式ドキュメントを教材化し、22章・約145,000字を数セッションで完成させています。差が出たのは並列実行のスループットでした。

この検証の概要

結論：並列実行が最大の収穫

この検証で最も明確な改善点です。

先行プロジェクトは逐次処理だったが、今回は3〜5並列で短縮効果が顕著だった。

具体的には、コア章8章を3セッション分の並列で消化しています。同じ手順・同じテンプレートを使いながら、実行の仕方だけを変えた結果です。

手順が固まっているからこそ並列化できます。1本目で型を作り、2本目でスループットを上げる——この順番が効率的です。

再現性の高い二段構成

この検証で確立したパターンです。

1. セキュリティ章で個別にプラン依存を書く（並列で分担）
        ↓
2. 最後に統合マトリクスを自分で書く

「セキュリティ章で個別にプラン依存を書く」「最後に統合マトリクスを自分で書く」の二段構成は再現性が高いと評価しています。

個別の調査は分担できますが、横断して比較する作業は分担できません。集めた情報を1つの判断軸にまとめる工程は、全体を見ている人が担当する必要があります。

結果として、この統合章がシリーズの中核になっています。

ai-train=no という区別

この検証で見つかった、実務上重要な知見です。

先行対象は Allow: / でAI学習も明示許可だったのに対し、今回の対象は ai-train=no でした。ただし ai-input=yes / search=yes のため、参照目的の利用は可能です。

「学習用途と参照用途を区別する」robots.txtの運用が一般化しつつあります。

これは実務上の分岐点です。同じ「クロールしてよいか」でも、何に使うかによって可否が変わります。外部ドキュメントを扱う作業では、この区別を確認する手順が必要になります。

エージェントが承認待ちで止まる

並列実行で発生した問題です。

初回のエージェントが「計画提示・承認待ち」で停止しました。

対処は、プロンプトに「即着手・確認不要・最後まで完遂」を明記して再投入することでした。

改善策として、エージェントプロンプトのデフォルトに「即着手・確認不要・Writeまで一気通貫」を含めるという運用に変更しています。

並列で走らせている場合、1つが承認待ちで止まっていることに気づきにくくなります。止まらない前提を明示しておく必要があります。

大量のsitemapをどう扱うか

もう1つ、規模による問題が出ました。

sitemap.xmlがフラット形式で約1,000 URLあり、取得のサンプリング上限により一部のURLはナビゲーションからの推定採用になりました。

改善策は2つです。

• sitemapが大量の場合は、最初に対象ディレクトリ配下のみフィルタリングしてからカテゴリ分類する
• 推定採用したURLは、ソース一覧で個別にマークすると後段の追跡が楽になる

「確実に取得したもの」と「推定で採用したもの」を区別して記録しておく——後から検証する人にとって、この区別は重要です。

調査で見えたプラットフォームの構造

教材化の過程で整理できた、実装時に効く知識です。

• AIインフラの境界を4章で整理 — v0 / AI Gateway / MCP / Sandbox / Agent がそれぞれ何を担うのかを構造化
• ドキュメントの所在が製品ごとに分かれている — 独立サブドメインにあるもの、複数系統に分かれているものがある
• デフォルト設定の変更履歴 — 新規プロジェクトではデフォルト化されているが、既存プロジェクトは手動切替という機能がある
• 特定バージョン未満で常時キャッシュミスになるバグなど、組み合わせ依存の既知問題
• マネージドサービスの移管 — 一部のデータストア製品が他社サービスへ移管され、自社継続は限られた製品のみ

まとめて読むと「今どの機能が主流で、何が移管・廃止されたか」が分かります。断片的に情報を追っていると、既に移管済みの製品を前提に設計してしまうことがあります。

Changelogは網羅せず軸で意味づける

教材としての可読性を担保するための判断です。

Changelogダイジェストを網羅ではなく5トピック軸で意味づけしました。

変更履歴を全件並べても読めません。「何が起きているか」の軸に整理し直すことで、読み物として成立します。

プラン依存表には見直し前提を書く

未解決課題として明記されている点です。

プラン依存表は特定時点の理解で記述しており、プラン変更頻度を考えると四半期単位で見直しが必要です。

あわせて、変化の速い領域については別ライフサイクルで管理する方針も出ています。AI関連機能は半年〜1年単位で見直す前提です。

教材の中で、更新頻度が違う部分を分けておく——これは長く使う資料を作るときの設計判断になります。

コスト対効果

22章・145,000字超の教材を数セッションで完成。手作業換算で数十時間相当のリサーチ・執筆を短縮という評価です。

また、成果物は二次展開の素材にもなります。同じ内容を記事・講座・SNS投稿へ展開する際の元ソースとして再利用できます。

よくある質問

1本目と2本目で何が変わりましたか？

並列実行のスループットです。先行プロジェクトは逐次処理でしたが、今回は3〜5並列で進め、短縮効果が顕著でした。手順とテンプレートは同じものを使っています。

すべてをAIに書かせているのですか？

統合章は自分で書いています。個別の調査は並列で分担できますが、横断して比較する作業は分担できません。この二段構成は再現性が高いと評価しています。

並列実行で気をつけることは？

エージェントが承認待ちで止まることです。プロンプトに「即着手・確認不要・最後まで完遂」を明記しておく必要があります。並列で走らせていると、1つが止まっていることに気づきにくくなります。

外部ドキュメントの利用可否はどう確認しますか？

robots.txtで「学習用途」と「参照用途」が区別されている場合があります。今回の対象は参照は可、学習は不可という指定でした。この区別を確認する手順を組み込んでおく必要があります。

まとめ

• 手順が固まっているから並列化できる。1本目で型を作り、2本目でスループットを上げる
• 「個別章は並列で分担、統合章は自分で書く」の二段構成は再現性が高い
• robots.txtは「学習用途」と「参照用途」を区別する運用が一般化しつつある
• 並列実行ではエージェントが承認待ちで止まる。「即着手・確認不要・完遂まで」を明記する
• 大量のsitemapは対象ディレクトリでフィルタしてから分類。推定採用したURLは個別にマークする
• Changelogは網羅せずトピック軸で意味づけると読み物として成立する
• 変化の速い領域は別ライフサイクルで管理し、更新前提を明記しておく

同じ作業を2回やると、1回目には見えなかった改善点が出てきます。手順を残しておくと、2回目以降の速度がまったく変わります。

株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のナレッジ整備とAI導入を支援しています。ご相談はお問い合わせフォームから、継続的な伴走支援についてはAI参謀をご覧ください。