コード生成の基礎 ── LLM は何を書けて、何を書けないか── AI がコードを書く原理と限界を、最初に地図化する

01LLM がコードを書く原理 ── 「次の一語」を当て続けているだけ

まず、いちばん誤解されやすい点をはっきりさせます。LLM は、プログラムの意味を理解して書いているわけではありません。やっているのは、きわめて単純な作業です ── 「これまでの文字列の続きとして、次に来る確率がいちばん高い語（トークン）は何か」を予測し、一つずつ並べているだけです。この仕組みは、2017 年に発表された Transformer（＝トランスフォーマー、文章の各語がどの語に注目すべきかを計算する仕組み）という構造の上に成り立っています。

コードも、LLM にとっては文章の一種です。def と書けば、その後には関数名が続く確率が高い。for i in と書けば、繰り返しの対象が続く。膨大な公開コードを学習しているので、こうした「続き」の予測が、驚くほど自然なプログラムに見えるわけです。

ここで大事なのは、この予測が最適化しているのは「正しさ」ではなく「もっともらしさ」だという点です。文法的に自然で、よくある書き方に似てさえいれば、たとえ動かないコードでも、LLM は自信たっぷりに出力します。原理を一言でまとめると、こうなります。

02得意と不得意 ── 境界は「学習データにどれだけあったか」で決まる

「続きを予測する」という原理から、得意・不得意の境界がそのまま導けます。学習データに大量にあるパターンは得意、めったにないパターンは不得意。これでほぼすべて説明がつきます。

Chen らが 2021 年に発表した Codex（＝コード生成用の GPT）の評価研究は、この境界を数字で示しました。基本的な関数を書かせる HumanEval（＝人手で作った 164 問のコード課題）というテストで、一発で正解する率は 3 割前後。ただし、同じ問題に何十回も挑ませ、そのうち一つでも正解があればよいとする条件なら、正解率は大きく上がります。「一発では外すが、数を撃てば当たる」 ── これが LLM のコード生成の素顔です。以後のモデルで精度は上がっても、この性質そのものは変わっていません。

03ハルシネーションの罠 ── 存在しない関数を、堂々と呼ぶ

LLM の限界がいちばん危険な形で出るのが、ハルシネーション（＝もっともらしい嘘）です。存在しないライブラリ、実装されていない関数、間違った引数の順序 ── これらを、LLM は正しいコードとまったく同じ自信で書きます。「たぶん間違っています」とは、まず言ってくれません。

なぜ起きるのか。原理に戻れば明らかです。LLM は「ありそうな続き」を書くので、「あってほしい関数」が、あたかも実在するかのように出力されるのです。たとえば「日付を和暦に変換する関数がありそうだ」とモデルが判断すれば、実在しない to_wareki() のような呼び出しを平然と書きます。見た目は完璧で、動かして初めて壊れます。

04人の役割は何か ── 書き手から、検証者・設計者へ

ここまでを踏まえると、AI 時代のプログラミングで人間が担う役割が見えてきます。AI が「書く」を引き受けるほど、人間の仕事は「何を書かせるか」と「書かれたものが正しいか」へ移ります。手を動かす人から、枠を決める人・確かめる人へ。

具体的には、人間に残る仕事は次の 3 つに絞られます。

• 要件を定義する ── 何を作りたいのか、どんな入力にどんな出力を返すべきか。ここが曖昧だと、AI は曖昧なまま「ありそうな」コードで埋めてしまう
• 正しさを検証する ── 出てきたコードが本当に動くか、境界条件で壊れないか、要件を満たすか。原理からいって、ここは AI に任せきれない
• 責任を負う ── 公開・納品・本番投入の判断。「AI が書いたから」は、どんな場面でも言い訳にならない

「AI がコードを書くなら、人は楽になる」。この理解は半分だけ正しい。書く手間は減りますが、検証と設計の責任はむしろ重くなります。この非対称さを、シリーズを通じて何度も確かめていきます。

05検証が必須である理由 ── 「動いた」は「正しい」ではない

AI が書いたコードを一度動かし、期待どおりの結果が出た。そこで安心するのが、いちばんよくある落とし穴です。「動いた」は「正しい」ではありません。たまたま与えた入力で動いただけで、別の入力で壊れる余地はいくらでも残っています。

人が全部書く従来のプログラミングと、AI 生成コードの検証は、力点が違います。整理すると、次のようになります。

だから AI プログラミングでは、テスト（＝入力と期待される出力を並べ、自動で照合する仕組み）が「あればよいもの」から「必須のもの」へ格上げされます。人が書いたコードなら省いてもよかった検証を、AI 生成では省けません。速く書ける分、確かめる工程を厚くする。これがバランスの取り方です。

06医療系ソフトの注意 ── 生成できても、そのまま使えない領域

製薬・医療の現場でこのシリーズを読む方に、特に強く伝えたい点があります。AI がコードを「生成できる」ことと、そのコードを医療の文脈で「使ってよい」ことは、まったく別の話です。

患者データを扱う、投与量を計算する、診断や治療の判断に関わる ── こうしたソフトウェアは、医療機器ソフトウェアとして国際規格 IEC 62304（＝医療機器ソフトウェアのライフサイクル規格）の管理下に入ります。この規格は、開発の各工程で「誰が・何を・どう検証したか」の記録（トレーサビリティ）を求めます。「AI が生成したので中身の根拠は説明できません」は、この枠組みでは通りません。

さらに、医療・医薬に関わる情報を出力するソフトを作るなら、薬機法の広告規制が背後に控えます。薬機法では、誇大広告の禁止は第 66 条、未承認医薬品等の広告禁止は第 68 条、販売情報提供活動における情報提供の適正化は第 68 条の 2 に置かれています。AI が生成した説明文やレポートであっても、これらの物差しはまったく緩みません。判断は「誰が書いたか」ではなく「何が書かれているか」でなされます。

07導入の順序 ── リスクの低いところから、確かめながら広げる

では、現場に AI プログラミングをどう入れていくか。原則はひとつです ── 失敗しても被害が小さいところから始め、検証の仕組みを整えながら、少しずつ責任の重い領域へ広げる。逆順、つまり最初から本番の重要処理に AI を入れるのは、いちばん避けたい進め方です。

• 段階 1 ── 使い捨ての作業: 一度きりのデータ整形、ログの集計、下書きの生成。間違えてもやり直せる領域から手をつける
• 段階 2 ── 反復する内部作業: 定型レポートの自動化、社内ツールの補助。テストを付けて、繰り返し使えるかを確かめる
• 段階 3 ── 検証を伴う本番: 人のレビューとテストを必ず通す前提で、業務プロセスに組み込む
• 段階 4 ── 規制対象: 患者安全・医療機器・規制情報に関わる領域。IEC 62304 等の枠組みと、正式な審査を通してのみ

どの段階にも共通する柵が、第 5 節で述べた検証です。段階が上がるほど、確かめる工程を厚くする。速度を上げる目的は、浮いた時間を検証に回すためだと考えると、順序を誤りません。

08シリーズ全 10 回の地図

本シリーズが扱う 10 回の構成を、あらかじめ地図にしておきます。読み進めるときの羅針盤にしてください。

1. 第 01 回
   コード生成の基礎 ── LLM は何を書けて、何を書けないか（本回）

   原理と限界の全体地図、シリーズの出発点
2. 第 02 回
   Copilot 活用 ── 補完型 AI の実務作法

   エディタ内で使う AI、補完を信頼しすぎない書き方
3. 第 03 回
   対話型コーディング ── ChatGPT / Claude との進め方

   指示の与え方、文脈の渡し方、往復の設計
4. 第 04 回
   プロンプト設計 ── AI に伝わる指示の書き方

   要件を枠として渡す技術、曖昧さを減らす
5. 第 05 回
   テストと検証 ── AI コードを信頼する仕組み

   自動テスト、境界条件、レビューの型
6. 第 06 回
   デバッグ ── AI と一緒に原因を探す

   エラーの読み方、AI への渡し方、根本原因の追い方
7. 第 07 回
   エージェント型開発 ── AI が複数手順を自走する

   自律実行の光と影、任せる範囲の設計
8. 第 08 回
   セキュリティと機密 ── コードと情報をどう守るか

   秘匿情報の扱い、生成物の脆弱性
9. 第 09 回
   製薬の現場実装 ── 規制下で AI を使う

   IEC 62304、薬機法、社内審査との両立
10. 第 10 回
    統合 ── AI プログラミングをチームに根づかせる

    運用ルール、責任分担、組織としての設計

09他章との接続 ── AI Marketing・資材審査との読み合わせ

AI Programming シリーズは、本サイトの他の章と次のようにつながります。読み合わせると、AI をめぐる理解が立体的になります。

• AI Marketing 第 1 回 ── マーケティング再定義 ── コンテンツが AI で大量生成される時代の全体地図。本シリーズは、その「作る側の技術」を扱う
• AI Marketing 第 5 回 ── 速度と審査のバランス ── 生成物を human-in-the-loop（＝人が途中に介在する仕組み）でどう審査するか。検証の考え方は本シリーズ第 5 回と共通
• 資材審査シリーズ ── 生成物を最後に受け止める審査の実務。コードでも資材でも、「作れる」と「使える」の間には審査がある

AI がコードを書く時代は、たしかに来ました。ですが、その「書く」は、意味を理解して書いているのではありません。学習データの中でもっともらしい続きを並べているだけです。だからこそ、定型的な作業では驚くほど速く、前例の無い設計や厳密な計算では静かに間違えます。存在しない関数を、正しいコードと同じ自信で書く ── この性質は、モデルが賢くなっても消えません。

この地図が示す結論はシンプルです。AI に書かせ、人が確かめる。速く書ける分だけ、確かめる工程を厚くする。とりわけ製薬・医療の現場では、生成できることと使えることの間に、検証と記録と規制という壁があります。次回は、この地図を手に、いちばん身近な入口 ── エディタの中で行を補完する Copilot 型 AI の実務作法へ進みます。