この記事でわかること
- AIへの指示書の「必ず」は守られない。必ず守らせる決まりは機械で検査する
- 規約は中身より、根拠と承認の記録が無いことが引き継ぎで問われる
- 決まりは写して配らず1か所から配り、食い違いを機械で止める
AIを使う開発会社の多くは、「社内の規約に沿ってコードを書いています」と説明します。では、その規約は誰が決め、なぜその基準なのか。別のエンジニアに引き継ぐときや、他の会社に手伝ってもらうときに、説明できるでしょうか。AIで開発していると、誰も決めていない基準が、いつの間にか会社の基準になっていることがあります。
弊社では2026年8月、社内のすべてのプロジェクトにかけているコーディング規約（コードの書き方の決まり）を見直しました。AIへの指示書に書いていた決まりを機械の検査へ移し、規約の出どころを調べて根拠を書き残し、1か所から全プロジェクトへ配る形にしています。何を確かめ、どう決めたかを順にお伝えします。
AIへの指示書の「必ず」は、仕組みにしないと守られない
弊社の開発では、Anthropic の開発用AI「Claude Code」に、役割ごとの指示書を持たせていました。規約に沿っているかを確かめる役もその1つで、指示書には「実装の後、取り込む前に必ず起動する」と書いていました。
2026年8月8日、私の問いをきっかけに、全プロジェクトの作業の記録をさかのぼり、各役割が実際に起動した回数を数えました。規約を確かめる役が動いたのは、通算1回でした。この方式では、AIが「この役を呼ぼう」と判断したときにしか動きません。指示書に「必ず」と書いても、強制する力は無かったということです。
そこで同じ日に、機械で判定できる決まりは、変更を取り込むたびに必ず走る自動の検査へ移しました（6つのプロジェクト）。中身を空にしたエラー処理や、大きくなりすぎたファイルなどは、AIが見落としても検査が止めます。
既存のコードには、規約に合わない箇所がすでにあります。まとめて直すと動きが変わるおそれがあるため、既存の違反は件数ごと記録しておき、新しい違反が増えたときだけ止める形にしました。新しいファイルにわざと違反を書くと止まることも、全プロジェクトで確かめています。
決まりは、中身より先に「根拠」を問われる
翌8月9日、私から次の指摘をしました。会社固有のルールを作った記憶がない。一覧を出して、世の中的にまともかも示してほしい。今後エンジニアが引き継ぐときや外注に手伝ってもらうときに、「何このルール」「品質的にアウト」と言われたら困る、というものです。
出どころを調べると、規約の実体は、AIの開発環境を最初に整えたとき（2026年5月）に入っていた汎用のひな形でした。それがそのまま会社の規約として、全プロジェクトの自動チェックに載っていました。「1ファイル800行まで」「1つの処理は50行まで」といった数値の根拠も、誰がいつ承認したかの記録もありません。説明できない基準で、変更の取り込みを止めていたことになります。
そこで、8つのルールを1つずつ、業界で広く使われている基準と照合しました。
出典：社内のコーディング規約の棚卸し記録（2026年8月9日）
中身に大きな問題はありませんでした。業界標準より厳しかった1点は、標準と同じに揃えると決めました。弊社の企業サイトのコードで比べると、この決まりへの違反は51件から28件に減りました。コードは1行も触っていません。標準に合わせれば、もともと違反ではなかったものです。
数値の根拠については、取り繕わないことにしました。800行・50行といった値は、実際のコードを測って決めた値ではありません。そこで「熟慮して決めた」とは書かず、業界の中でどの位置にあるか、全プロジェクトのコードに当てたときに実際どう働いているかを、後から示しました。たとえば800行の上限に当たっていたのは全社で7件だけで、日常の開発を止めていません。50行のほうは日常的に当たるため、取り込みを止めない「警告」にとどめています。
これらを、全ルールの一覧・理由・業界との比較・承認日を載せた文書にまとめ、私が承認しました。基準の数値を変える、警告を止める扱いに上げる、ルールを増減する、といったときは承認を取り直すことも、同じ文書に書いてあります。
決まりは写して配らず、1か所から配る
決まりを各プロジェクトに写して配ると、写した後の変更が届きません。実際、社内の経営管理システムは、自動チェックの設定をSkillPort（エンジニアの経歴書を管理する自社サービス）から写して作られたため、後からSkillPortに足した秘密情報の混入検査が入らないまま、3か月放置されていました。
いまは、すべてのプロジェクトが持つべき自動チェック（秘密情報の混入検査、AIによる二次レビューなど）を、組織の設定から一括でかけています。これから作るプロジェクトにもかかる設定です。
規約のファイルは、正本を1か所に置き、各プロジェクトへ配る写しに、版と「内容の指紋」（中身から計算した短い記号）を入れています。変更を取り込むたびに、写しが正本と合っているかを自動で照合し、写しが手で書き換えられていたり、正本が新しくなったのに古いままだったりすると止まります。
- 1正本を直し、版を上げる
- 2全プロジェクトへ写しを配り直す
- 3取り込みのたびに、写しと正本を照合する
- 4手で書き換えた写し・古い写しは止める
決まりを変えるたびに、この流れで全プロジェクトがそろう
仕組みを動かし始めた日には、検証用の変更で写しを1行だけ書き換え、正しく止まることを確かめました。「設定した」と「実際に止まる」は別のことなので、両方を見ています。
AIを使う開発会社に頼むときに役立つ3つのこと
規約は、一覧と根拠で見せてもらってください
システムは、作った会社だけが触り続けるとは限りません。別のエンジニアや別の会社が引き継ぐときに、規約の根拠が説明できないと、「何このルール」から話が始まります。どんな決まりで書いているのかを、理由と一緒に一覧で見せてもらえるかを確かめると安心です。
「必ず〜します」が、心がけか仕組みかを聞いてください
「必ずテストします」「必ずレビューします」は、人やAIの心がけであれば、忙しいときや見落としたときに抜けます。それを何が止めるのか、通らなければ取り込めない仕組みがあるのかを聞くと、言葉どおりに守られるかが分かります。
古いシステムを直すときは、新しい違反だけを止める
長く使っているシステムを直すとき、古いコードを規約に合わせて全部書き直すと、費用がかさむうえに動きが変わるおそれがあります。私たちは、既存の違反は件数ごと記録したうえで、新しく書く部分だけを規約で止める進め方をとります。直す範囲と費用を、そのうえで一緒に決めます。