AIエージェントの成果物を組織標準に揃える、
フォーマットキットと文体リンターの設計
提案書は会社の標準フォーマットで。対外ドキュメントの文体は、読み手である職業人の水準に。人間の組織であれば、この種の標準は先輩のレビューと口伝で伝わり、数年かけて体に入っていきます。コーディングエージェントには、その経路がありません。しかも弊社では、複数のプロジェクト、複数の端末、二種類のエージェント（Claude Code と Codex）、さらにその配下のサブエージェントが、日々スライドや報告書、各種のドキュメントを作っています。一枚一枚は悪くないのに、並べると別の会社が作ったように見える。この状態を放っておくと、標準は存在しないのと同じになります。本記事では、弊社が社内で積み重ねてきた仕組みのうち二つ、会社標準のスライドフォーマットキットと、ドキュメントの文体リンターを題材に、「組織標準をエージェントに配る」設計を整理します。
標準は、テンプレートを配っても揃わない
エージェントとの協働を始めた当初に試したのは、いちばん素朴な方法でした。よくできた提案書のファイルを「これに倣って」と渡す。結果は揃いません。エージェントはテンプレートを出発点として扱い、善意で改良します。配色を少し変え、見やすさのために枠線を足し、項目に「01」「02」と番号を振り、章のラベルに英語を添える。一つひとつは合理的でも、積み重なると「AIが作った印象」の典型になり、会社の顔としては使えない資料になります。
次に試したのが、ルールファイルに一段落の指針を書く方法です。これも部分的にしか効きません。指針が長くなるほど薄まり、エージェントは覚えている部分だけを適用します。三つ目は、対話の中でその都度指摘する方法です。指摘は次のセッションには残らず、同じ指摘が別の端末で繰り返されます。三つの方法に共通する原因は、標準が「一つの形」でしか存在していないことでした。人間は反復の中で標準を身につけますが、エージェントには毎回、標準そのものを届けなければなりません。届けるためには、実行できる形（テンプレート）、変えてはならないことを定めた正本（仕様書）、外れたことを検出する検査（機械チェック）の三つが同時に要る。この認識が、以降で述べる設計の出発点です。
付け加えると、コンサルティングファームにとって成果物の体裁が揃っていることは、美意識の問題ではありません。閲覧者は資料の細部から組織の統制を読み取ります。フォーマットの揺れは、それだけで減点になります。
キットの中身: テンプレート・正本・ビルド・見本
スライドフォーマットキットは、社内限定の小さなリポジトリです。中身は次のとおりで、ファイル数は11しかありません。
rstreet_slide_format_kit/ ├── README.md … セットアップと作成手順 ├── FORMAT_GUIDE.md … デザイン仕様・表記ルール・品質チェックの正本 ├── template/ │ ├── slide_template.html … 全コンポーネント実例入り・ロゴ埋め込み済み │ └── slide_template.pdf … テンプレートをそのままPDF化した出力見本 ├── samples/ … 実データ例で埋めた確認用デッキ（HTML/PDF） ├── scripts/build_slide_pdf.sh … Chrome headless で HTML→PDF 変換 └── assets/ … ロゴ3種（透過PNG）
テンプレートは16:9（1280×720px）のHTMLで、ロゴは画像データを埋め込んだ自己完結の1ファイルです。文言や数値の入る箇所はすべて【】で囲んだプレースホルダーになっており、サンプルの数値や金額も例外なく【】に入っています。この徹底には理由があります。置換漏れの検査が、「grep -c '【' の結果が0である」という一行の機械検査に落ちるからです。送付物に残ったプレースホルダーは最も恥ずかしい事故のひとつですが、その検査は人の注意力に頼らなくてよくなりました。
正本にあたるのが仕様書です。カラートークン、フォントサイズの一覧（pxとpt相当）、面の表現ルール、コンポーネントの一覧、表記ルール、品質チェックの手順が書かれ、確定した値には「変更禁止」と明記されています。ここが要点で、テンプレートは標準そのものではなく、標準を実行可能にした形にすぎません。標準は仕様書に定義され、テンプレートはその写像であり、見本PDFは「期待される見た目」の答え合わせ用です。エージェントは自分の生成物を見本と見比べられるので、言葉で説明するより早く、確実に差分に気づきます。
ビルドスクリプトは Chrome の headless モードでHTMLをPDFに変換し、失敗時には必ず非0で終了します。エージェントの手順は「テンプレートを複製し、【】を差し替え、grep で残存ゼロを確認し、スクリプトでPDF化し、全ページを目視する」の五段階に固定されました。判断の余地を残したのは内容だけで、体裁には残していません。
キットには版と変更履歴があり、フォーマットの改善はすべて版を上げて再配布します。枠線ボックスの全廃、面をフラットな塗り分けに限定、連番のゼロ埋め禁止、一文中の太字と細字の混在禁止。いずれも運用の中でのレビューの指摘がそのまま仕様になったもので、履歴には理由が残っています。標準は最初から完成しているものではなく、指摘を吸収して版を重ねるものだという前提が、この履歴に表れています。
配り方: 正本はひとつ、参照はすべての端末から
キットができても、それを全端末のすべてのエージェントが必ず参照する状態を作らなければ意味がありません。弊社の配布は三層になっています。
第一層は正本の置き場所で、社内限定のリポジトリです。ロゴ素材を含むため外部には出しませんが、社内では常にここが唯一の参照元です。第二層は各端末のミラーで、社内情報を集約しているハブのリポジトリの中に置き、毎晩動く定期ジョブが同期スクリプトを呼びます。スクリプトは正本の最新の版をミラー側の記録と照合し、一致していれば何もしない。更新があるときだけミラーを丸ごと差し替え、版と同期時刻を書き残します。差分の判定と差し替えを機械に任せることで、どの端末のミラーも同じ版に揃います。
第三層が、エージェントに読ませる規則です。弊社ではユーザーレベルのルールファイル（端末上の全プロジェクトに効く CLAUDE.md）に、短い一節を置いています。内容は、スライド資料はキットに必ず従うこと、ミラーの場所と、参照できないときは正本から直接取得すること、CSSやデザイントークン、ロゴの配置サイズを変えないこと、【】残存ゼロの確認とビルドスクリプトによるPDF化、送付用PDFはmacOSで最終生成すること、キットは社内限定であること、そしてフォーマットを改善したらキット本体を更新して再配布することです。ルールファイルが持つのは「どこに正本があるか」と「譲れない数点」だけで、重い仕様は必要になったときにキット側から読まれます。ルールファイルは毎セッション丸ごと読み込まれるため、公式のガイドでも短く保つことが勧められています。指し示すものと、指し示されるものを分けるのは、その意味でも理にかなっています。
毎日起動しない予備の端末には、夜間ジョブを登録しません。代わりに「スライド作成の作業を始めるときに、まず同期スクリプトを実行して更新の有無を確かめる」という規則を、その端末のルールファイルに書いています。手順は引き継ぎ書として残し、全端末の設定が終わったら引き継ぎ書自体を削除する。仕組みを増やしすぎず、端末ごとの事情に合わせて更新経路だけを変える判断です。
なお、配布の形はいまや複数あります。Claude Code には組織全体に配る管理ポリシー用の CLAUDE.md の置き場所があり、複数プロジェクトでルールを共有するためのディレクトリやシンボリックリンクの仕組みもあります。手順と付属スクリプトをまとめて配るスキルは Agent Skills というオープン標準に沿っており、Codex 側でも同じ形式が読めます。社内向けのプラグイン配布も可能です。弊社が「素のリポジトリとミラー」を選んだのは、二種類のエージェントと人間が同じファイルをそのまま読める共通項がそれだったからで、要件が変われば形も変えます。要は、正本がひとつであること、参照が壊れないこと、更新の経路がはっきりしていること。この三点が満たされるなら、配布の手段は道具の進化に合わせて選び直せばよいと考えています。
文体もまた標準である: 指摘をリンターに変換する
体裁が揃ったあとに問題として残るのが文体です。弊社の文体の基準は、対外ドキュメントのレビューを重ねる中で固まってきました。たとえばある案件向けの40ページを超える資料では、指摘は多岐にわたりました。個人向けセミナーの語彙（「持ち帰っていただく」「お帰りの際には」）、「ございます」の多用、読み手を見下す断り書き（「プログラミングの知識は一切不要」）、同じ情報の重複掲載、サービス精神過多の運営注記、「オープニング／クロージング」という章名、そして本文が参照している別紙が実在しないこと、などです。
ここで行うのは、指摘箇所を直すことだけではありません。同時に二つのことをします。ひとつは、指摘の背後にある考え方を原則として、その領域のルールファイルに恒久化すること。想定読者は企業で働く職業人であり、砕けていないが堅苦しくもない水準で書く。過剰な丁寧語は使わない。情緒的・個人向けの言い回しを避ける。同じ情報を手を変え品を変え繰り返さない。資料中で参照する別物は必ず実物を作る。もうひとつは、その原則を機械的に検査するリンター（文体の検査スクリプト）に落とし、PDF化と送付の前に必ず通す関門にすることです。
# 文体リンターの規則（抜粋・要旨）: 正規表現, 重大度, 指摘文, 許容する文脈
('ございま', 'ERROR', '「ございます」は不要。です／ますで言い切る',
許容: 'ありがとうございます' 等の定型)
('持ち帰', 'ERROR', '個人向けセミナー調。「得られる成果」等へ')
('！', 'ERROR', '感嘆符は使わない')
('大丈夫', 'WARN', '過剰な安心付与。書かなくても伝わるなら削る')
('【', 'ERROR', 'プレースホルダーが残存')
('配布資料|別紙', 'INFO', '参照物の言及。実物ファイルの存在を確認する')
# ERROR があれば終了コード1（PDF化・送付に進めない）
# WARN は理由を持って残してよい / --strict で WARN も失敗扱い
設計上の要点は、重大度を三段階に分けたことと、許容する文脈を規則ごとに持たせたことです。ERRORは必ず直すもので、一件でも残れば終了コードが非0になり、後続の工程へ進めません。WARNは文脈次第で残してよいもので、「大丈夫」を機械的に禁じると不自然な文が生まれるため、判断を人とエージェントに戻します。INFOは「配布資料」「別紙」「プロンプト集」といった参照物への言及を拾い、その実物が本当に存在するかを確認させます。先の資料では、本文が参照していた四つの別紙（プロンプト集、手順の対応表、トラブルシューティング、テンプレート集）が実在しないことがレビューで分かり、別紙として実物を新たに作りました。INFOはその再発を機械で防ぐための規則です。スライド構造のHTMLでは、指摘をページ番号つきで返すようにしてあるため、修正は該当ページを開くだけで済みます。
語彙を正規表現で拾う方法は素朴に見えますが、ここではそれが正解でした。規則が具体的なフィードバックから生まれているため、検出したい表現が最初から特定できているからです。目的は日本語一般の品質ではなく、弊社の文体に揃えることにあります。より一般的な検査には既存の道具があり、日本語では textlint に技術文書向けのルール集や「AIらしい書き方」を検出するルール集があります。後者は表現ではなく構造を縛ることで自然な文にする方針を掲げていて、示唆に富みます。英語圏の Vale も、規則を提案・警告・エラーの三段階で持つ設計です。弊社のリンターはこれらの上に重ねられる薄い層で、汎用の検査と会社固有の語彙は別の層で持つのがよいと考えています。
文章のルールと機械の検査、どちらに置くか
二つの仕組みを作る過程で、置き場所の判断基準がはっきりしてきました。ルールファイルに書いた文章は、エージェントにとって文脈であって強制ではありません。公式のドキュメントもその旨を明記し、確実に止めたい操作にはフックを使うよう案内しています。したがって、意図と理由は文章に置きます。エージェントは理由から一般化するので、「なぜ枠線を使わないのか」が書いてあれば、仕様に載っていない場面でも同じ判断ができます。一方で、客観的に判定できることは機械に置きます。プレースホルダーの残存、禁止語彙、ビルドの失敗。正規表現で書ける規則は正規表現にし、判断が要る規則は例を添えた文章に留めて、重大度は高くてもWARNにする。
こうして振り返ると、弊社の運用に繰り返し現れる型が見えます。フィードバックを受けたら、第一に日付と理由つきの文章のルールにし、第二に実行可能な形（テンプレート、キット、スキル）に落とし、第三に検査（grep、リンター、フック）を置く。以前の記事では、この型を一つのリポジトリの中で扱いました。今回の単位は会社です。単位が広がっても型は変わらず、変わったのは配布と同期の層が要ることだけでした。
数の話も一つ添えておきます。エージェントの数が増えるほど、標準の揺れは数に比例して増えます。人が一人ずつレビューして揃える方法は、この比例に耐えられません。標準をキットとして配り、検査を機械に置くと、揃い方はエージェントの数に依存しなくなります。エージェントを増やす前に整えるべきものが何かは、ここから逆算できます。
運用して見えたこと
運用の中で確かになったことがいくつかあります。第一に、見本は言葉より効きます。仕様書に何行書くより、期待される見た目のPDFを一枚同梱するほうが、エージェントの生成物は正確に寄ります。第二に、「変更禁止」は明記しないと守られません。禁じたうえで、唯一の例外（全フォントサイズの一括等倍スケール）を仕様に定義しておくと、揺れも硬直も防げます。第三に、改善は必ず本体へ戻すこと。ある案件で見つけた改良をその案件の中だけで済ませると、標準は静かに分岐します。改版のたびにバージョンと理由を残して再配布する運用が、この分岐を防いでいます。
リンターについても学びがありました。規則を書いてすぐ分かったのは、正当な表現まで拾ってしまう規則があることです。「ありがとうございます」の中の「ございます」、あるいは「世界標準時」の中の「世界」。許容文脈とWARNの段階があってはじめて、日々通せる関門になります。すべてをERRORにすると関門は迂回されるようになります。実際に運用している資料でも、WARNは数件を理由つきで残しています。もうひとつは前述の参照物の実在確認で、言及だけが立派で実物がない片手落ちは人間の資料でも起きますが、言及を機械で拾って実在を確かめさせれば見逃しません。
環境依存の切り分けも必要でした。フォーマット（レイアウト・寸法・サイズ）はどの環境でも同一ですが、字形はOSのフォントに依存します。そこで、送付用PDFの最終生成はmacOS（ヒラギノ環境）を標準とし、Linuxで生成したPDFは社内確認用に留める、と仕様に書きました。同一性の範囲を正直に定義しておくほうが、後で「なぜ違うのか」を調べるより安上がりです。最後に、キットはロゴを含む社内限定資料なので、クライアントのリポジトリや外部へそのまま共有しないことを規則にしています。標準を配りやすくするほど、配ってはいけない先の定義も同時に要ります。
まとめ
標準はこれまで人の中に宿っていました。エージェントと働くいま、標準はエージェントが読むファイルと、機械が実行する検査の形でしか存在できません。会社らしさをその形に詰め直したとき、それはエージェントの数が増えるほど薄まる制約ではなく、数が増えるほど価値を増す資産に変わります。書いたものだけが引き継がれ、配ったものだけが揃う。弊社がクライアントの現場で行っている定着の支援も、突き詰めればこの詰め直しの作業であり、自社の運用で先に試すことが、その品質を支えていると考えています。