AIエージェント2体で、本を書き始めた話

2026年版「生成AIセキュリティガイド」の執筆環境を作り直しました

こんにちは、現役IT執行役員のグイグイです⚡

今、私は2025年に出版した「生成AIセキュリティガイド」の2026年改訂版を書いています。

去年書いたものをベースにしつつ、2026年時点の最新事情を反映して、かなり大きめにアップデートしようとしています。

ただ、今回変えたのは中身だけではありません。

執筆環境そのものを、かなり大きく変えました。

去年は、いろいろなAIを使って調査し、Notionに情報をまとめ、最終的にWordで原稿を書いてPDF化する、という流れでした。

当時としては、かなりAIを使った執筆スタイルだったと思います。

でも今回は違います。

今回は、

• Claude Desktop の CoWork

• OpenAI の Codex アプリ

この2つのAIエージェントを、同じプロジェクトフォルダで使っています。

つまり、AIをただ使うだけではなく、

という感じです。

ちょっと未来っぽいことを言っていますが、やっていることはかなり現実的です。

PC上に共同作業フォルダを作り、そこに原稿、調査資料、タスク、メッセージ、組版設定などを全部置く。

それをClaudeとCodexが読めるようにする。

そんな形です。

去年はNotionとWordで書いていた

2025年版を書いたときは、主にNotionとWordを使っていました。

ざっくり流れとしては、

• AIで調査する

• Notionに情報を整理する

• Wordで原稿を書く

• PDFにする

という感じです。

これはこれで、当時はかなり便利でした。

特にNotionは、調査メモや構成案をまとめるにはかなり使いやすいです。

ただ、長めの本を書いてみると、いろいろ見えてきます。

まず、Wordがつらい。

いや、Wordが悪いと言いたいわけではありません。

普通の文書を作るには便利です。

でも、数百ページ規模の本を書き、大きく構成を変えたり、章ごとに整理したり、AIエージェントに触らせたりしようとすると、かなりしんどい。

そしてNotionも、情報量が増えてくると重くなります。

軽いメモなら最高です。

でも、調査資料、章構成、原稿、参考リンク、画像、メモ、レビュー観点……みたいなものが増えてくると、

となります。

特に今回は、扱う内容も去年より増えています。

• PCI DSS 4.0

• AIエージェント

• ローカルLLM

• AIセキュリティ

• 企業導入

• データガバナンス

• AI時代の開発プロセス

• エンタープライズ利用時の注意点

普通に重いです。

テーマが重い。

資料も増える。

調査も増える。

原稿も増える。

だったら、執筆環境そのものを変えた方がいいなと。

そこで今回は、かなり開発寄りの構成にしました。

VS Codeで本を書く

今回の執筆は、VS Codeで管理しています。

本の原稿なのにVS Code。

普通に考えると少し変かもしれません。

でも、自分としてはかなり自然です。

というのも、今回の執筆環境はほぼ開発プロジェクトだからです。

実際のプロジェクト構成は、こんな感じです。

フォルダ構成としては、

• chapters/

• research/

• appendix/

• assets/

• scripts/

みたいに分けています。

chapters/ には章ごとの本文。

research/ には調査資料。

appendix/ には付録。

assets/ には画像や図版。

scripts/ には変換や補助処理に使うもの。

さらにルートには、

• AGENTS.md

• task.md

• MESSAGES.md

• vivliostyle.config.js

などを置いています。

これ、もう完全に本の原稿というより、開発プロジェクトです。

でもこの形が、今回のようなAIエージェント前提の執筆にはかなり合っています。

AIエージェント向けのルールを書く

今回かなり大事にしているのが、AIエージェント向けのルールファイルです。

具体的には、AGENTS.md を用意しています。

ここには、このプロジェクトでAIエージェントが守るべきルールを書いています。

例えば、

• この本の目的

• 執筆方針

• 文体ルール

• セキュリティ観点

• ClaudeとCodexの役割分担

• Git運用ルール

• やってはいけないこと

などです。

要するに、AIエージェント用のプロジェクト憲法みたいなものです。

特にCodexでは AGENTS.md を前提にしやすいので、このファイルにプロジェクトルールを集約しています。

Claudeについても、必要に応じてこの AGENTS.md を読ませる運用にしています。

本来Claude系では CLAUDE.md を使う文脈もありますが、今回は複数AIエージェントで共有しやすいように、プロジェクト共通のルールとして AGENTS.md に寄せています。

ここが結構大事です。

AIエージェントは賢いです。

でも、放っておけば勝手にいい感じに全部やってくれるわけではありません。

むしろ、賢いからこそ危ないところもあります。

それっぽく進めてしまう。

それっぽくまとめてしまう。

それっぽく正しそうな文章を書いてしまう。

だからこそ、最初にルールを置く。

どこまでやってよいのか。

何を勝手に変えてはいけないのか。

最終判断は誰がするのか。

このあたりを明確にしています。

これは本当に、開発チームのルール作りに近いです。

task.mdで作業を管理する

次に task.md です。

これは作業管理用のファイルです。

ここには、

• どの章を進めるのか

• 誰が担当するのか

• どこまで終わったのか

• 次に何をするのか

• 保留事項は何か

といった情報を書いています。

Claudeが調査した内容をCodexが整理する。

Codexが組版やファイル構成を調整する。

Claudeが本文の整合性をレビューする。

最後は私が確認して判断する。

そんな感じで役割を分けています。

もちろん、AIエージェント同士が、本当に人間のチームのように自律的に会話して、勝手に完璧に連携してくれるわけではありません。

そこまで魔法ではないです。

ただ、同じプロジェクトフォルダを見て、同じ task.md を参照することで、

を共有しやすくなります。

これがないと、毎回こちらが全部説明し直すことになります。

それはさすがに面倒です。

というか、それだとAIエージェントを使っている意味がかなり薄くなります。

MESSAGES.mdで非同期メッセージを残す

さらに MESSAGES.md というファイルも用意しています。

これは、AIエージェント間の引き継ぎノートのようなものです。

例えば、

• この章の構成を変えた

• この調査結果は古い可能性がある

• この用語は以後こちらに統一する

• 次に作業するAIはここを見てほしい

• このファイルは人間の確認待ち

みたいなことを書き残します。

人間同士の仕事でも、非同期の引き継ぎって大事ですよね。

AIエージェントでも同じです。

Claudeで作業したあと、次にCodexを開く。

Codexで作業したあと、またClaudeに戻す。

そのときに、毎回こちらが口頭で説明するのはしんどい。

だからプロジェクト内に、引き継ぎ用のメッセージを残す。

これが思った以上に効きます。

あー、これは完全にチーム開発だなと。

AIエージェントは、環境がないと迷う

今回やっていて改めて思うのは、AIエージェントは単体で賢くても、それだけでは足りないということです。

大事なのは、AIエージェントが迷わず動ける環境を作ること。

例えば、

• 本文はどこにあるのか

• 調査資料はどこにあるのか

• どのファイルを編集してよいのか

• どのファイルは参照だけなのか

• Git操作は誰がするのか

• Claudeは何を担当するのか

• Codexは何を担当するのか

• 最終的な判断は誰がするのか

こういう前提がないと、AIエージェントはわりと普通に迷います。

そして迷った結果、それっぽく作業します。

これが一番怖い。

特に今回書いているのは、生成AIセキュリティの本です。

内容の正確性も大事ですし、適当なことを書かれると困ります。

だから、AIに自由にやらせるというより、

という考え方にしています。

これは、かなり今後大事になる気がしています。

「AIを使う」だけなら、誰でもできます。

でも、AIエージェントを実務で使うなら、作業環境そのものを設計する力が必要になります。

本文は章ごとにMarkdownで書く

本文はすべてMarkdownで書いています。

しかも、1つの巨大ファイルではなく、章ごとに分けています。

例えば、

01_intro.md
02_pci_dss.md
03_ai_agent.md
04_local_llm.md

みたいな形です。

この方が圧倒的に管理しやすいです。

Wordで長い原稿を1ファイルで管理していると、後半かなりきつくなります。

章の順番を入れ替える。

一部をごっそり削る。

別の章に移動する。

表現を統一する。

差分を見る。

このあたりが、だんだん重くなってくる。

でもMarkdownで章ごとに分けておけば、かなり軽いです。

VS Codeで開ける。

検索できる。

AIエージェントが読める。

Gitで管理できる。

この時点でかなり強いです。

Gitで管理すると、思い切って変えられる

今回かなり大きいのが、Gitで原稿を管理していることです。

原稿も、設定ファイルも、タスク管理ファイルも、基本的にGitで管理しています。

これによって、変更履歴が全部残ります。

どの章をどう直したのか。

どの構成を変えたのか。

どのタイミングで大きく修正したのか。

全部追えます。

これが何に効くかというと、

ということです。

本を書いていると、途中で普通にあります。

「あ、この章は前に持ってきた方がいいな」

「この説明、丸ごと別章に移した方が自然だな」

「この構成、やっぱり違うな」

こういうとき、戻せる保証がないと怖いんですよね。

Wordでぐちゃっと直してしまうと、元に戻すのが面倒です。

だから、ちょっと躊躇する。

でもGit管理していれば、

が成立します。

これがかなり大きい。

執筆って、書くだけではありません。

削る。

入れ替える。

試す。

戻す。

また試す。

この繰り返しです。

Gitがあると、この試行錯誤のコストが一気に下がります。

開発では当たり前の考え方ですが、本の執筆にも普通に効きます。

むしろ長編執筆こそGitで管理した方がいいんじゃないかと思うくらいです。

MarkdownとAIエージェントは、やっぱりほぼ完璧に相性がいい

MarkdownとAIエージェントの相性がいいことは、やる前から分かっていました。

これは別に今回初めて気づいたわけではありません。

分かっていたけど、実際にここまで本格的に組んでみて、

となりました。

少なくとも、私の今回の執筆環境では、MarkdownとAIエージェントはほぼ完璧に噛み合っています。

理由はシンプルです。

Markdownはテキストです。

構造が見える。

差分が見える。

Gitで管理できる。

AIが読みやすい。

人間も読める。

これが強い。

Wordのようなリッチなファイル形式は、最終的な見た目を整えるには便利です。

ただ、AIエージェントと共同作業するには、どうしても扱いづらい。

差分が見えにくい。

構造が読み取りづらい。

ファイル単位での分割や統合も面倒。

AIに部分修正させるにも、少し重い。

その点、Markdownはかなり素直です。

特に今回みたいに、

• Claude

• Codex

• VS Code

• Markdown

• Git

• Vivliostyle

をつなげると、全体がかなりきれいに噛み合います。

これは「試してみたら意外とよかった」という話ではありません。

もともと良いだろうとは思っていた。

実際にやってみたら、やっぱりめちゃくちゃ良かった。

そんな感じです。

最後はVivliostyleでPDFにする

今回は、最終的なPDF化にもWordを使いません。

Markdownで書いた原稿を、Vivliostyleで組版してPDFにします。

Vivliostyleは、MarkdownやHTMLをもとに、CSS組版でPDFなどを作れるツールです。

要するに、

• 本文はMarkdownで書く

• レイアウトや見た目はCSSで制御する

• 最終的にPDFにする

という流れです。

これもかなり開発寄りです。

Wordで見た目を手作業で整えていくのではなく、本文とスタイルを分ける。

本文は本文。

組版ルールは組版ルール。

設定は設定。

この分離がかなり気持ちいい。

今回の流れをざっくり書くと、こんな感じです。

Claude / Codexで調査・整理・レビュー
        ↓
章ごとにMarkdownで執筆
        ↓
Gitで履歴管理
        ↓
Vivliostyleで組版
        ↓
PDF化

かなりソフトウェア開発に近い書籍制作です。

でも、今のAIエージェント時代には、この方が自然だと思っています。

本を書くというより、執筆プロジェクトを運営している

今回やっていて一番面白いのは、感覚が「本を書く」だけではなくなっていることです。

もちろん文章は書いています。

でも実際には、それ以上にプロジェクトを運営している感覚があります。

人間である私は、

• 全体構成を決める

• 方針を決める

• 品質を判断する

• 最終責任を持つ

• AIに任せる範囲を決める

AIエージェントは、

• 調査する

• 草稿を作る

• 構成を整理する

• 差分を修正する

• 参考情報をまとめる

• レビュー観点を出す

という役割を担う。

これは、かなり開発チームに近いです。

AIエージェントをただの便利ツールとして使うのではなく、プロジェクトの中に参加させる。

ただし、好き勝手に動かすのではなく、ルールと構造を与える。

この感覚がかなり大事だと思っています。

AI時代の知的生産は、環境設計が大事になる

生成AIが出てきてから、よく言われるのは「プロンプトが大事」という話です。

もちろん、それはそうです。

プロンプトは大事です。

ただ、AIエージェントを使う段階になると、それだけでは足りない気がしています。

大事なのは、

です。

どこに情報を置くか。

どう役割分担するか。

どう進捗を共有するか。

どう引き継ぐか。

どこまで任せて、どこから人間が判断するか。

ここを設計しないと、AIエージェントは本当の意味では活きません。

これは、たぶん2026年以降かなり重要になってくると思います。

作り方そのものも、2026年版にする

2025年版の「生成AIセキュリティガイド」は、AIを使って書きました。

でも2026年版は、少し違います。

AIエージェントが同じプロジェクト文脈を参照できる環境を作り、その中で執筆プロジェクトとして運営しています。

NotionとWord中心の執筆から、

VS Code、Markdown、Git、Vivliostyle、Claude、Codexを組み合わせた執筆へ。

かなり開発寄りです。

でも、生成AIセキュリティのように、技術的で、情報量が多く、更新性も求められる本を書くなら、この形はかなり理にかなっていると思います。

内容だけを2026年版にするのではなく、作り方そのものも2026年版にする。

今回は、そこをかなり意識しています。

正直、まだ試行錯誤中です。

たぶん、この先も普通にハマると思います。

Vivliostyleの組版でハマるかもしれないし、AIエージェント間の引き継ぎで微妙なズレが出るかもしれない。

でも、それも含めて面白い。

去年は、AIを使って本を書いていた。

今年は、AIエージェントが共同作業しやすい環境を作って、本を書いている。

この変化は、自分の中ではかなり大きいです。

「ああ、これが私にとっての2026年の執筆環境なんだな」

と感じています。

#生成AI
#AIエージェント
#AI活用
#Claude
#Codex
#VSCode
#Markdown
#Git
#技術書執筆
#知的生産