AIが書いたコード、最後の関門は人が押す ― 自動チェックを承認者に据える品質の守り方

AIが書いたコードの品質は大丈夫なのか。AIを使う開発会社に業務システムを頼むとき、多くの方が気にされる点です。確かめるべきは「AIの性能」より、AIが書いたものを、何が・どの順番で止めるのかです。人が目で見るだけでは、少人数の体制ではどこかで抜けが出ます。

弊社では、社内のすべての開発で、必須の自動チェックを通らない変更は取り込めない作りにし、そこにAIによる二次レビューを重ねています。自社で開発・運営している「SkillPort」（エンジニアの経歴書を一か所で管理するサービス）では、本番へ公開する最後の一押しを人が行う形にしました。この形を決めるまでに何を確かめ、どう判断したかを順にお伝えします。

少人数の開発では、自動チェックを「承認者」にする

変更を取り込む前に「別の人の承認」を必須にするやり方があります。ただ、弊社が開発の管理に使っている仕組みでは、変更を出した本人は自分の変更を承認できません。実質1人で進めるプロジェクトで人の承認を必須にすると、承認がいつまでも埋まらず、毎回決まりを飛び越えて取り込むことになります。それでは決まりが無いのと同じで、飛び越えることが習慣になってしまいます。

そこで、人の承認の代わりに、毎回同じ基準で判定する自動チェックを必須の関門に据えました。社内では「機械の承認者」と呼んでいます。

最低限：鍵や個人情報など、秘密の情報がコードに混ざっていないかの検査
コードのあるプロジェクト：規約の検査、型の検査（データの形の食い違いを見つける）、自動テスト、組み立て（ビルド）

SkillPortでは、これらが通らない変更は取り込めません。

一方で、結果が安定しないチェック（外部のリンク切れの確認など）は、必須の関門にしていません。通ったり落ちたりする関門は、結局また飛び越える理由になるからです。

コードを能動的に触る人が2人以上になったプロジェクトでは、人の承認も必須に加えます。作成者以外の人が承認できるので、人のレビューが機能するからです。

AIのレビューは重ねる。ただし回数に上限を置く

自動チェックで分かるのは、決めた基準に合っているかまでです。処理の誤りや、変更が別の場所を壊していないかは、中身を読まないと分かりません。そこで、変更の取り込み依頼が出るたびに、AI（Anthropic の Claude）が差分を読んで指摘を書き込む二次レビューを、社内のすべてのプロジェクトに自動でかけています。

この二次レビューは指摘を残すだけで、取り込みを止めません。指摘を採るかどうかは人が決めます。認証や決済など影響の大きい変更では、必要に応じてセキュリティに絞ったレビューを別に行います。

回し方は、運用の中で一度決め直しています。以前は修正のたびにレビューを回していましたが、社内の別のシステムでは、1つの変更で7巡・1時間超かかりました。2巡目以降の指摘の大半は「1巡目の修正が新しく作った穴」で、直せばまた出る構造でした。そこで依頼を出したときの1回だけにしましたが、今度は1巡目の指摘を受けて直した部分が誰にも検査されず、本番へ出す前にまとめる変更（リリース用）には、一度もレビューが入っていませんでした。

2026年9月6日、次のように決め直しました。

1巡目：変更の全体を読む
2巡目：1巡目の後に直した部分だけを読み、「このままだと壊れる」指摘だけを出す
3巡目以降は回さず、人が読む

巡目は、人の心がけではなく仕組みの側が数えて打ち切ります。決める前に、Claude Code の公式のレビュー機能の設計（初回の後は重要な指摘だけを出す）を確かめ、同じ考え方であることも確認しました。

1つの変更にかかったAIレビューの回数

いまの上限 2巡

上限を置く前の実例7巡（1時間超）

出典：SkillPort 開発記録（2026年9月6日）

決め直した後の最初の変更では、1巡目で指摘5件、直した後の2巡目は指摘なし、3巡目は回らずに終わりました。

AIの指摘も、そのままは採りません。この見直しの作業中、ある指摘に添えられていた直し方の案は、実際に動かすと動きませんでした。指摘にあったもう一つの案を採り、動くことを確かめてから取り込んでいます。

本番へ出す最後の一押しは、人が行う

同じ9月6日、SkillPortの公開の流れも作り替えました。取り込んだ変更は、まず検証用の環境に反映されるだけで、本番には人が「昇格」の操作をしたときにだけ出ます。切り替えた後、1回の取り込みで検証用の環境に反映され、本番向けは保留のまま止まることを確かめてから、私の判断で昇格しました。

AIが書いた変更が本番に出るまで

1変更の取り込みを依頼する
2必須の自動チェックを通す
3AIの二次レビュー（最大2巡）
4人が読んで取り込む
5検証用の環境で確かめ、人が本番へ昇格する

この移行の途中で、AIの二次レビューが見落としを拾いました。自動で作られる部品の更新の変更が、人の目を通らないまま本番へ出てしまう隙間です。関わる仕組みの動きは一つずつ把握していましたが、移行の途中に限って、それらが組み合わさると隙間になることには気づけていませんでした。指摘は「このままだと壊れる」に当たるもので、本番への自動公開を止める作業を予定より前倒しして塞ぎました。

同じ日の二次レビューは、お客様からのセキュリティの質問票に答えるための回答集で、直し漏れていた行も拾っています。そのままなら、事実と違う運用を外部に答えるところでした。

人が読んで取り込み、人が本番へ出す。その手前に、毎回同じ基準で止める自動チェックと、人とは別の目で読むAIのレビューを置く。どれか1つに頼らず、役割の違うものを重ねています。

AIを使う開発会社に頼むときに役立つ3つのこと

「何が止めるのか」を、止めるものと止めないものに分けて聞いてください

「AIのレビューも入れています」だけでは、品質の担保になっているかは分かりません。通らなければ取り込めない関門はどれか、指摘を残すだけのものはどれかを分けて聞くと、仕組みの実態が見えます。私たちの場合、自動チェックは止める関門で、AIのレビューは止めずに人へ判断材料を渡す役割です。

AIのレビューの「回数」と「採否を決める人」を聞いてください

AIのレビューは、回せば回すほど良くなるものではありません。上限を決めずに回すと、直すたびに新しい指摘が出て終わらなくなります。何巡まで回すのか、指摘を採るかどうかを誰が決めるのかが決まっていれば、その会社はAIの指摘を判断材料として扱っています。

本番へ出す操作を、誰がするかを決めておきます

本番へ出すことは、業務を止めるかもしれない操作です。私たちは、作ったシステムを本番へ出す操作を、自動ではなく人の操作にしています。発注いただくシステムでも、検証用の環境で確かめてから本番へ出す流れと、その操作を誰がいつ行うかを、最初に一緒に決めます。