「AIを使っているんですよね。だったら期間はもっと短くできませんか」。見積もりの場でこの質問が出たとき、答えに詰まった経験はないでしょうか。書く速さが上がっているのは事実です。それでも工期が思ったほど縮まないのは、詰まっている場所が「書く」ではないからです。
同じ構図を、言語処理系の側から言葉にした例があります。
ZigはLLMを使った投稿を行動規範で禁じている
プログラミング言語Zigは、公式サイトの行動規範（Code of Conduct）に「Strict No LLM / No AI Policy」という項を置いています。規範が及ぶのは、Codeberg上のziglangの組織、IRCの#zig、開発用のZulipです。2026年5月24日に改訂された現在の文面は、次を禁じています。
- LLMが生成した内容の投稿（コードでも文章でも）
- LLMが生成した内容の言い換え
- LLMによる編集（綴りや文法の修正を含む）
- LLMによる翻訳（英語は推奨だが必須ではなく、母語で書いてよい）
- LLMで考えを出し、その結果を共有すること（文章を自分で書いても同じ）
- LLMでバグを探すこと
- チャットボットやLLMのサービスを使ったことについて話すこと
2025年11月の時点では、同じ項は「Issue、プルリクエスト、バグトラッカーのコメント（翻訳を含む）にLLMを使わない」という短い形で、サイトの規範とリポジトリのREADMEに載っていました（READMEは今もこの形です）。Issueのテンプレートには2025年5月から、CopilotなどのLLMでIssueを書かないよう求める案内が置かれています。2026年5月の改訂で、生成した内容の言い換え、綴りや文法の修正、考えを出すこと、バグ探し、LLMの利用について話すことまでが明記されました。規範の文面は理由を書いておらず、項の末尾にアシモフの短編『Profession』へのリンクを置いているだけです。
なお、規範が律するのは上に挙げた場だけです。Zigを使った自社の開発でAIを使うかどうかは、この規範の対象ではありません。
作者が挙げた理由
理由は、作者のAndrew Kelley氏がJetBrainsのYouTubeチャンネルのインタビュー（Zigのフォーラムで2026年5月27日に共有）で語っています。以下は、InfoQが9月23日に伝えた発言に基づきます。編集部は動画の該当箇所を確認できていません。
InfoQによれば、Kelley氏が挙げた要因は2つです。コードの量が増えても人の側の手は増えないこと、そして出来上がるソフトウェアの質が下がることです。Kelley氏は、そうした寄稿は「例外なくゴミ（invariably garbage）」で、価値がないどころかマイナスだと言います。レビューの時間を取られ、何度かやり取りしてから、書いた本人が中身を分かっていないと気づく。こちらのコメントをチャットに貼り、その出力を返してくるだけだ、という説明です。
同じくらい重要なこととして、Kelley氏はZigの教育的な役割を挙げています。レビューに使える時間は限られているので、誰に時間を投じればより良いプログラマー、より良い貢献者に育つのか、誰が通りすがりの貢献者なのかを見極めたい。AIを使う人はいつも後者で、何も学んでおらず、後にコアチームに加わることもない。Kelley氏は、限られたレビューの時間を誰に賭けるかというこの考え方を「contributor poker（貢献者ポーカー）」と呼んでいます。
Zigの2026年6月16日のお知らせによれば、コアチームはこれまで、活発な貢献者の中からだけ選ばれてきました。コアチームになると、プルリクエストのレビューとマージの判断を任されます。Kelley氏の説明と合わせると、レビューは、将来レビューする側に回る人を育てる時間でもあることになります。品質の低さだけでなく、レビューという投資の回収先が消える、という指摘として読めます。
ZigがリポジトリをGitHubからCodebergへ移したのは2025年11月26日です。移行のお知らせは、GitHub Actionsの不具合でCIの処理が滞り、masterブランチへのコミットさえ検査されない状態になったことを最も大きな理由に挙げ、GitHubがCopilotでIssueを書く機能を押し出していることが、規範への違反の一因だと見ている、とも書いています。インタビューでは、非営利の運営のほうが安定している、とも話しています（InfoQ）。
この話が見積もりに効くところ
受託の現場に置き換えると、Zigのメンテナは「レビューする側」です。レビューできる人が1人か2人の体制なら、同じ制約はもっと強くかかります。
AIでコードを書く速さが3倍になっても、レビューする人の数が同じなら、増えるのはレビュー待ちの行列です。行列が伸びると、レビューが薄くなるか、工期が伸びるかのどちらかに寄ります。前者を選ぶと、AI生成コードが半年で腐るで扱った形になります。
つまり、見積もりで短縮できるのは主に「実装の時間」で、「読んで判断する時間」は残ります。たとえば実装が工数の半分を占める案件なら、書く速さが倍になっても全体は25%しか縮みません（単純な計算の例です）。ここを説明しないまま「AIを使うので早くなります」と言うと、あとで自分の首を絞めます。
決めておくとよいこと
顧客との合意と、社内の工程の両方で、次を先に決めておくと後が楽になります（編集部の整理です）。
見積もりでは、実装とレビューを別の行にする。 一緒にしていると、AIで縮む部分と縮まない部分の区別が説明できません。分けておけば、「実装は縮みます、レビューは縮みません」と根拠のある形で言えます。
レビューの担当が1人なら、それを制約として明示する。 人を増やせないなら、それが工期の下限です。これは交渉の材料ではなく、事実の共有です。
レビューで見るものを絞る。 全部を同じ密度で見るのは、量が増えた状況では成り立ちにくくなります。何を必ず人が見て、何を機械に任せるかを決めます。工程への組み込み方はAIコードレビューを受託の工程に入れるに、コメントの種類の分け方はレビューの2種類のコメントに整理しました。
依存しているOSSの寄稿方針を確認する。 案件の途中で依存ライブラリの不具合に当たり、上流へ報告や修正を送る場面はあります。そのプロジェクトがZigのような方針なら、AIのコードレビューで見つけた不具合を、AIでまとめた文章で報告すること自体が規範に触れます。Zigは英語への翻訳にLLMを使うことも禁じ、代わりに母語で書いてよいとしています。人が確かめ、人が書く段取りを工程に入れておきます。どこまでを禁じるかはプロジェクトごとに違い、OpenJDK・Linuxカーネルのstaging・Rustの線の引き方はAI生成コードを納品されたらで比べました。
社内なら、禁止より先に「使ったら書く」
ここからは、Zigとは別の線の引き方です。Zigは使うこと自体を禁じ、使ったことについて話すことも禁じています。申告を求める方針ではありません。一方、書き手とレビューする側が同じチームにいる受託や社内の開発では、禁止より先に、使ったことを書いてもらう運用から始められる、と編集部は考えています。
理由は、読み方が変わるからです。人が書いたコードには、書いた人の理解の跡が残りやすい。変数名の付け方、コメントの置き場所、直前のコミットとの関係。レビューする側は、そこから「この人はここを分かっている」「ここは怪しい」を推し量って、見る密度を配分しています。
生成されたコードは全体が同じ調子で整って見えるため、この跡を頼りにしにくい、というのが編集部の見方です。生成されたと分かっていれば、仕様との突き合わせを先に、書きぶりの確認を後にする、という順に切り替えられます。
具体的には、プルリクエストの説明欄に一行、どの範囲を生成させたかを書きます。なお、発注側の受け入れ基準として申告を求めるだけでは機能しにくい点は、先に挙げたAI生成コードを納品されたらで整理しました。ここで言うのは、同じチームの中でレビューの順番を決めるための申告です。
反論として成立しないもの
「レビューもAIにやらせればよい」という返しは、半分だけ正しい。形式の確認、明らかな不整合、コーディング規約への違反の検出は、機械に任せやすい部分です。
成立しないのは残りです。この変更が仕様と合っているか、顧客が言っていた制約に触れていないか、半年後にこの構造で困らないか。これらは案件の文脈を知っている人にしか判断できません。Kelley氏がレビューを育成への投資と見ているように、判断できる人はレビューを重ねるうちに育つもので、生成量に比例しては増えません。
次にやること
進行中の案件で、直近1ヶ月のレビュー待ち時間を測ってください。プルリクエストが出てからマージされるまでの中央値です。この数字が実装にかかる時間より長いなら、AIを足しても納期は縮みにくい状態です。レビュー待ちの列の見方はAIが量産するプルリクをどう捌くかでも扱いました。
縮めたいなら、手を入れる先は生成の側ではなく、レビューできる人の数か、レビューで見る範囲の絞り方のどちらかです。
2026年9月28日に、Zigの行動規範（ziglang.org）とその変更履歴、Codeberg上のziglang/zigのREADMEとIssueのテンプレート、Zigのお知らせ2本（2025年11月26日のCodebergへの移行、2026年6月16日のコアチームの紹介）を直接確認しました。Kelley氏の発言は、InfoQ（2026年9月23日）の報道が引用したものに基づき、DevClass（6月1日）の報道とも照らし合わせました。JetBrainsのインタビュー動画は、この作業環境から再生・書き起こしの取得ができず、発言を動画で確認していません。規範の項の時期は、2025年5月23日にIssueのテンプレートへLLMについての案内が加わったこと、同年11月22日にサイトの規範とREADMEに載ったことを変更履歴で確認しました。それ以前にGitHubのwikiにあった文面は確認できていません。見積もりや工程の整理、申告についての考えは編集部の見解で、特定の案件の実績値ではありません。
AIを組み込んだ開発の工程設計や、レビュー体制を含む見積もりのご相談はグリームハブへ。
Sources
- Code of Conduct（Strict No LLM / No AI Policy） — Zig
- 行動規範の変更履歴（content/en-US/code-of-conduct.smd） — ziglang/ziglang.org（Codeberg）
- ziglang/zig（README の Contributing） — Codeberg
- Issueのテンプレートの案内（.forgejo/ISSUE_TEMPLATE/config.yml） — ziglang/zig（Codeberg）
- Migrating from GitHub to Codeberg — Zig
- Welcoming Our Newest Core Team Members — Zig
- 報道：Andrew Kelley Interview: Why He Built Zig, Banned AI Contributions, and Moved Zig off GitHub — InfoQ
- 報道：Zig creator seeks ‘uncompromising perfection’ before blessing 1.0 — DevClass
