一つのAIへ全部頼めば早いと思っていた
SAMEKORO LABの記事を作り始めた頃は、文章を考えることも、ファイルを直すことも、AIへまとめて頼めば早いと思っていました。
実際には、記事の方向を相談する時間と、リポジトリへ正しく反映する作業では、必要な確認が違います。文章だけ良くてもシリーズの順番やリンクが壊れては公開できず、ビルドが通っても体験と違う内容が入れば自分の記事にはなりません。
そこで、ChatGPT、Codex、人の役割を分けました。
人が最初と最後の判断を持つ
人が決めるのは、今回実際に何をしたか、何を記事へ残したいか、何を公開しないかです。タイトルの最終決定、確認できた事実、掲載できるスクリーンショット、公開状態も人が判断します。
AIが自然な文章を提案しても、実際に起きていない失敗や感情は採用しません。AWSアカウントID、メールアドレス、認証情報などを出さない基準も、最初に要件として渡します。
最後に公開してよいかを決めるのも人です。AIの出力が完成形ではなく、確認の対象だと考えるようになりました。
ChatGPTは企画と編集を担当する
ChatGPTには、本文を書く前の整理を中心に任せます。
- タイトル案
- 記事の狙いと読者
- 今回だけの新しい学び
- 見出し構成
- 必要な構成図とスクリーンショット
- 前後の記事とのつながり
いきなり本文を書かず、先に構成を確認することで、AWSサービスの説明へ寄りすぎるのを防げます。既存記事と重複している場合も、本文を作る前なら方向を変えやすくなります。
本文の編集では、説明より体験を先に置けているか、同じ言い回しを繰り返していないかを見ます。ただし、経験そのものをChatGPTに作らせることはしません。
Codexはリポジトリの変更と検証を担当する
構成と本文が決まったあと、Codexには本命リポジトリでの作業を任せます。
- 既存の
AGENTS.mdと記事原本を確認する content/articlesへMarkdown原本を追加・更新する- 既存コンポーネントとCSSを再利用して図を実装する
- サイト用HTMLとnote用Markdownを生成する
- シリーズ導線、内部リンク、画像参照を確認する
npm.cmd run checkを実行する
ファイルを実際に読み、変更後の生成物まで確認できることがCodexへ任せる理由です。文章を貼り付けて終わりではなく、サイトの一部として成立するところまで一つの作業にできます。
Markdown原本を一つにした
サイト本文とnote本文を別々に直す運用では、片方だけ更新し忘れる可能性があります。現在はcontent/articlesのMarkdownを原本にし、サイト用HTMLとnote用Markdownを生成します。
これにより、人とChatGPTは内容を確認し、Codexは生成と検証を繰り返せます。修正対象がどこか迷いにくくなり、同じタイトルや本文を二か所で直す必要もありません。
一方、生成されたから正しいとは限りません。H1の数、前後リンク、記事URLのindex.html、CSS・JavaScript・画像の参照まで自動検証へ含めています。
分担しても、会話の受け渡しが残った
役割を分けると、次は同じ前提を何度も説明する問題が出ました。記事はAWSの手順書にしない、既存記事を読み直す、本文前に構成案を確認する、公開できない情報を出さない、といった条件です。
長い依頼文へ毎回すべて書くと、重要な今回固有の事実が埋もれます。逆に短くすると、以前決めた方針が抜けることがありました。
この問題に対して、繰り返すルールをAGENTS.mdへ移しました。次回の記事では、そのファイルをルート用と記事用に分けた理由を扱います。
企業の制作フローと、個人の自由さ
企業なら、企画、執筆、技術レビュー、編集、実装、公開承認を別の担当者が持つことがあります。AIを使う場合も、入力情報、レビュー責任、履歴、公開基準を組織で決める必要があります。
個人開発では一人で全部を判断できます。その自由さを、確認を省く方向ではなく、役割を切り替えやすくする方向へ使いました。相談、実装、検証を分けることで、今どの視点で見ているかを意識できます。
まとめ
ChatGPTは記事の企画と編集、Codexはリポジトリの変更・生成・検証、人は要件と事実と公開可否を判断する。この分担にして、記事作成とサイト実装を同じ流れで回せるようになりました。
AIを増やしたことより、任せる範囲と任せない判断を決めたことが大きな変化でした。次回は、その境界を毎回の長い説明ではなく、AGENTS.mdへ残した話をまとめます。