プログラミング能力がChatGPTより優秀

「AIにコードを書かせる」という行為は、もはや先進的なエンジニアだけの特権ではなくなりつつある。そうした文脈で注目を集めているのが、Anthropic社が開発するAI「Claude」のプログラミング能力である。本稿では、「なぜClaudeのプログラミング能力が高く評価されているのか」を、どのベンチマークで、いつ時点の、どのバージョン同士を比較した結果なのかまで明示しながら整理する。そのうえで、規制産業の実務家にとって本当に重要な論点――GxP環境で使うソフトウェアをAIに書かせた場合、バリデーションの責任はどうなるのか――を、FDA・eCFR・ISO/IEC・ISPEの一次情報に基づいて解説する。

「ChatGPTより優秀」を検証可能な言明に置き換える

プログラミング未経験者がAIの助けを借りてWebアプリを作成し、ベテラン開発者がAIとのペアプログラミングで生産性を高める――そのような光景が、2026年の現場では日常となっている。

そうしたなかで、「ClaudeはChatGPTよりプログラミングが得意だ」という言い方が広く流通するようになった。しかし規制産業に身を置く者にとって、この種の断定はそのままでは扱えない。「AがBより優れている」という命題は、比較の条件を書かなければ検証も反証もできない主張だからである。

具体的には、少なくとも次の4点が示されていなければ、その主張は根拠を持たない。

本稿では、この4条件を満たす形でのみ数値を引用する。逆に、これらが特定できない伝聞・印象論は、たとえ広く語られていても本稿では採用しない。

そもそも「AIのプログラミング能力」とは何か

評価される能力の多様性

AIのプログラミング能力を一言で語るのは難しい。その理由は、プログラミングという行為自体が多層的なスキルの集合体だからである。具体的には、以下のような能力が評価の対象となる。

• コード生成能力：自然言語による指示から、動作するコードを生成する能力
• デバッグ能力：エラーの原因を特定し、修正案を提示する能力
• コード理解能力：既存のコードベースを読み解き、意図を正確に把握する能力
• リファクタリング能力：動作するコードを、より読みやすく・保守しやすい形に改善する能力
• 長文脈への対応能力：大規模なコードベースを扱う際に、文脈を正確に保持し続ける能力

これらの能力を総合的に評価するためのベンチマーク（性能評価基準）として、業界では「SWE-bench」や「HumanEval」といった標準化された指標が用いられている。

代表的なベンチマークの性格

ここで重要なのは、SWE-bench Verified はモデル単体を測っていないという点である。Anthropicは自社の技術記事で「SWE-benchはAIモデルを単独で評価するのではなく、エージェントシステム全体を評価している」「同じ基盤モデルを使っていても、スキャフォールディング（足場）次第でスコアは大きく変わりうる」と明言している（Anthropic, Claude SWE-Bench Performance）。この一点だけでも、ベンチマークスコアを「モデルの実力」として単純比較することの危うさが分かる。

Claudeが優位とされた領域 ― 数値と測定条件

SWE-bench Verified の公表値

2024年後半から2025年前半にかけて公表された各社の一次情報を、測定条件を併記した形で整理すると次のようになる。

この表から読み取るべきことは、「Claudeが勝った」という結論ではない。読み取るべきは次の3点である。

1. 同一時点の比較ではないClaude 3.7 Sonnet（2025年2月）とGPT-4o（2024年11月版）は、公表時点で3か月以上の開きがある。世代の異なるモデル同士の比較は、優劣の証明にはならない。
2. 同一条件の比較でもない63.7%と70.3%は同じモデルの同じ問題セットに対するスコアである。差の6.6ポイントは、モデルの能力差ではなく足場の作り方の差にすぎない。異なるベンダーが異なる足場で出したスコアを並べることには、そもそも限界がある。
3. 問題セットが揃っていないClaude 3.7 Sonnetの数値は489問、Claude Sonnet 4.6の数値は500問に対するものである。分母が違う数値を同じ列に並べれば誤読を招く。

コンテキストウィンドウの差は、すでに解消している

Claudeの強みとして頻繁に挙げられてきたのが、「コンテキストウィンドウ」の大きさである。コンテキストウィンドウとは、AIが一度に処理できる情報量を指す概念であり、人間に例えるなら「作業机の広さ」に相当する――机が広いほど、多くの資料を同時に広げて参照できる。数千行に及ぶ既存コードベースを読み込み、設計思想や命名規則を理解したうえで一貫性のある追加実装を行う場面で、この広さは意味を持つ。

ただし、この差を根拠に優劣を語ることは、本稿執筆時点ではすでに成立しない。

つまり2025年4月の時点で、コンテキストウィンドウの数値上の優位はすでに逆転しており、2026年2月には再び並んでいる。ハードウェア的・仕様的な数値の優劣は、数か月単位で入れ替わる。それを恒久的な優位として記事に書くべきではないというのが、本稿改訂から得られる第一の教訓である。

なお、コンテキストが長くなるほど初期の情報を「忘れる」現象は、LLM全般に共通する技術的課題である。仕様上の最大トークン数と、その全域を実効的に使えるかどうかは別問題であり、この点は各社とも認めている。

指示への忠実性と出力の予測可能性

開発現場でとりわけ重視されるのが、「指示通りに動く」という信頼性である。例えば、「Pythonのみを使用し、外部ライブラリは一切使わないこと」という制約を与えた場合、その制約を会話の後半まで一貫して守れるかどうかは、実務上の使い勝手を大きく左右する。

この点について、コード生成における指示遵守を評価するベンチマーク MultiCodeIF では、評価対象モデルのうち Claude 3.7 Sonnet が最高成績を示し、単一階層の制約における平均制約充足率は 63.0%、4ラウンドの診断フィードバックを経ると 83.4% に上昇したと報告されている（arXiv:2507.00699, 2025年7月）。

この「ルールに厳格に従う能力」という論点は、本誌読者に馴染みの深いコンプライアンス領域の概念と共鳴する部分がある。AIの振る舞いの予測可能性は、エンタープライズ（企業規模）での利用における品質保証の観点からも、重要な評価軸となっている。

コードの説明能力

プログラミングの専門知識を持たないビジネス担当者や品質保証担当者にとって、AIに求めるのはコードを「書く」能力だけではない。「なぜそのコードが問題なのか」「このアーキテクチャには何のリスクがあるか」を、非エンジニアにも理解できる言葉で説明できる能力も同様に重要である。単に答えを出すだけでなく、判断の根拠や代替案を合わせて提示する挙動は、レビューや監査の場面での活用を容易にする。

ただし、この「説明の丁寧さ」については、本稿執筆時点で客観的な測定結果を一次情報として確認できなかった。開発者コミュニティにおける定性的な評判として語られているものであり、検証可能なベンチマーク結果ではない点を明記しておく。

ベンチマークの限界 ― 2026年に何が起きたか

ここまで整理してきた数値の土台そのものが、2026年に入って大きく揺らいだ。これは本稿の主題にとって決定的に重要である。

SWE-bench Verified に対する提供元自身の否定

SWE-bench Verified を公開したOpenAI自身が、2026年2月23日に「Why SWE-bench Verified no longer measures frontier coding capabilities（なぜ SWE-bench Verified はもはやフロンティアのコーディング能力を測れないのか）」と題する分析を公表した。そこで指摘されたのは、次のような内容である。

OpenAIは同分析のなかで、より長い時間軸と現実的なコーディングタスクを扱う SWE-Bench Pro への移行をコミュニティに呼びかけた。さらに2026年7月8日には「Separating signal from noise in coding evaluations」を公表し、その SWE-Bench Pro にも同種の問題があることを指摘している。

最新世代のモデルは、そもそもこの指標を報告していない

実際、本稿執筆時点で最新世代のモデル発表では、SWE-bench Verified のスコアが主要指標として提示されなくなっている。Anthropicが2026年7月24日に発表したClaude Opus 5の発表資料では、Frontier-Bench v0.1、CursorBench 3.2、GDPval-AA v2、FrontierCode 1.1、OSS-Fuzz といった別系統の評価が並び、SWE-bench Verified の記載はない。OpenAIのGPT-5.5でも同様に、SWE-Bench Pro などが用いられている。

規制対応実務への接続 ― AIに書かせたコードの検証責任

ここからが、規制産業の実務家にとっての本題である。「どのAIが優秀か」という問いよりも、はるかに重い問いがある。GxP環境で使うソフトウェアをAIに書かせた場合、バリデーションの責任はどうなるのかという問いである。

結論：コードの出所は、免責事由にならない

まず原則を確認する。コードを誰が（あるいは何が）書いたかにかかわらず、規制上のバリデーション義務は一切変わらない。これはFDAの規則の文言から直接読み取れる。

電子記録・電子署名を扱うクローズドシステムの管理を定める 21 CFR Part 11 の §11.10(a) は、次のように定める。

ここで求められているのは、「正確性（accuracy）、信頼性（reliability）、一貫した意図された動作（consistent intended performance）、および無効または改変された記録を識別する能力を確保するための、システムのバリデーション」である。

この条文には、コードの作成者に関する記述が一切存在しない。社内の開発者が書いたか、外注先が書いたか、AIが生成したかは、条文の要求に何の影響も与えない。求められているのは「システムが意図した動作を一貫して行うこと」の立証であり、その立証責任は常に規制対象事業者の側にある。

QMSR施行後、製造・QMSソフトウェアの検証要求はどこにあるか

ここで、条番号を最新の姿に更新しておく必要がある。かつて自動化プロセスのバリデーションを定めていた21 CFR §820.70(i) を引用した資料が今なお流通しているが、本稿執筆時点の 21 CFR Part 820 は Quality Management System Regulation（QMSR）へと全面改正されており、当該条項は存在しない。現行のPart 820の構成は次のとおりである。

§820.10(a) は、製造業者に対し「ISO 13485（§820.7により引用組込み）の適用される要求事項および本パートのその他の適用される要求事項に適合する品質マネジメントシステムを文書化すること」を求めている。すなわち、QMSに用いるコンピュータソフトウェアの適用のバリデーション要求は、ISO 13485:2016 の該当要求事項（箇条4.1.6）を通じて課される構造に変わった。同箇条は、QMSで使用するコンピュータソフトウェアの適用のバリデーションに関する手順を文書化すること、初回使用前および変更後に（適切な場合に）バリデーションを行うこと、そのアプローチと活動をソフトウェア使用に伴うリスクに見合ったものとすること、活動の記録を保持することを求めている。旧QSRの条番号を引用したまま手順書を運用している企業は、この点を確認されたい（関連記事：なぜ遡って法が適用されたのか）。

FDA CSAガイダンスのリスクベースの考え方との関係

AI生成コードの検証を「どこまでやるか」を考えるうえで、直接の手がかりとなるのがFDAの Computer Software Assurance（CSA） ガイダンスである。ここでも版の確認が必要である。

CSAガイダンスの中核にあるのは、「ソフトウェアが意図したとおりに動作しなかった場合に、医療機器の安全性と品質が損なわれるリスク」に応じて、保証活動の程度を決めるという考え方である。これをAI生成コードに当てはめると、実務上の判断は次のように整理できる。

CSAガイダンスは、高いプロセスリスクを持つ機能に対してさえ、非スクリプト化テスト（unscripted testing）――アドホックテスト、エラー推測、探索的テストなど、テスト実施者の行動が文書化された手順で規定されていない動的テスト――が適していることがある、としている。ただし同ガイダンスは同時に、次の一点を明確にしている。

AI生成コードの検証においては、この原則がとりわけ重要である。「AIに書かせて、動いたので採用した」という運用は、非スクリプト化テストではなく単なる無記録の検証である。誰が、いつ、どのプロンプトで、どのモデルの、どのバージョンに生成させ、何を確認して受け入れたのか――この一連が記録として残っていなければ、CSAの枠組みに乗ることはできない。

なお、CSAはソフトウェアバリデーションの原則そのものを置き換えるものではない。原則論については、FDAの General Principles of Software Validation が依然として基礎文献である。CSAとの関係については、当社の連載記事「ER/ES実践講座（第7回）CSV保証は何が変わったか」もあわせて参照されたい。

GAMP 5 第2版のカテゴリ分類と、コンフィグレーション／カスタマイズの区別

医薬品領域を含むGxPコンピュータ化システムでは、ISPEの GAMP 5: A Risk-Based Approach to Compliant GxP Computerized Systems（第2版、2022年7月） が事実上の標準的枠組みとして参照される。第2版では、ソフトウェアのカテゴリが Appendix M4「Categories of Software and Hardware」で扱われ、その区分は次のように整理されている。

ここで実務上決定的に重要なのが、コンフィグレーション（設定）とカスタマイズ（作り込み）の区別である。カテゴリの判定基準は「その特定の用途向けにコンポーネントを作り出すために、どの程度の複雑さの活動が必要だったか」であって、「誰がその活動を行ったか」ではない。したがって――

なお、AI対応システムそのものの管理については、ISPEが2025年7月に ISPE GAMP Guide: Artificial Intelligence（290ページ）を発行しており、GAMP 5第2版と並行して用いることが想定されている。国内では、医薬品・医薬部外品製造販売業者等におけるコンピュータ化システム適正管理ガイドライン（平成22年10月21日 薬食監麻発1021第11号）が同様のカテゴリ分類を採用している。

生成コードのトレーサビリティをどう確保するか

規制対応の中核は、結局のところ要求仕様 → 設計 → コード → テストの追跡可能性である。AIを使うと、この鎖のうち「設計 → コード」の区間が人間の頭の中を通らずに飛び越されるため、放置すると鎖が切れる。実務では次の手順で鎖をつなぎ直す。

1. 要求仕様を先に確定し、承認するAIに投げる前に、URS（ユーザ要求仕様）ないし要求事項を文書化し、承認しておく。AIに要求仕様そのものを起草させる場合でも、承認は必ず人間が行い、承認記録を残す。
2. 機能仕様・設計仕様を要求仕様にひもづける各設計項目がどの要求に対応するかを、トレーサビリティマトリクスで対応づける。AIに設計を起草させた場合も、この対応づけは人間が検証する。
3. 生成の条件を記録する使用したモデル名とバージョン、実施日時、与えたプロンプト（またはその要旨と参照した仕様書の版）、生成物のリビジョンを記録する。同じプロンプトでも出力は再現しないため、「再現できる手順」ではなく「何が起きたかの記録」を残すという発想が必要である。
4. 人間によるコードレビューを必須工程に置くレビュー実施者、実施日、指摘事項、是正内容を記録する。レビュー実施者には、当該コードを評価しうる力量が求められる（力量の証拠は教育訓練記録として保持する）。デザインレビューとデザインベリフィケーションの違いを踏まえ、両者を混同しないこと。
5. テストを要求仕様にひもづけて実施・記録する各テストケースがどの要求を検証しているかを明示する。AIにテストコードを書かせる場合、「実装したAIと同じAIにテストを書かせると、同じ思い込みを共有したテストになる」リスクを認識し、要求仕様側からテスト設計を起こす。
6. 変更管理に載せるAIによる修正提案の採用も「変更」である。変更管理手順に従い、影響評価・再テスト範囲の決定・承認を経る。
7. 記録を保管する上記の記録群は、21 CFR §820.35（Control of records） や ISO 13485:2016 の記録管理要求、および電子記録として保持する場合は21 CFR Part 11（国内ではER/ES指針、平成17年4月1日 薬食発第0401022号）の要求に従って管理する。

設計成果物の束としてのDHFの考え方については、DHF（デザインヒストリーファイル）とは何かもあわせて参照されたい。

サプライヤ管理と第三者コンポーネント

AIコーディングツールを業務に導入するということは、新たなサプライヤを一社増やすことに等しい。ISO 13485:2016は購買プロセスにおける供給者の評価・選定・再評価と記録の保持を求めており、AIツールもその射程に入る。実務上、少なくとも次の点を評価しておきたい。

• モデルのバージョン管理と廃止（デプリケーション）方針――検証時に用いたモデルが、いつまで利用可能か。モデルが差し替われば、生成物の性質も変わる。
• 入力データの取扱い――社内の設計情報やソースコードをプロンプトとして送信する場合、それが学習に利用されるか、どこに保管されるか。機密保持と、場合により個人情報保護の論点になる。
• 可用性とサービスレベル――サービス停止時に、検証済みの成果物にアクセスできなくなることはないか。
• ライセンス上の論点――生成AIは公開されたソースコードを含む大量のデータで学習している。生成物が既存コードと実質的に同一である場合、元コードのライセンス条件（コピーレフト条項等）が問題になりうるという指摘が存在する。この論点は法域や事案により結論が分かれ、本稿執筆時点で確立した規制当局の見解は確認できていない。ただし、第三者コンポーネントの由来と利用条件を把握・記録するという実務は、オープンソース利用一般で従来から求められてきたものであり、AI生成コードについても同じ管理を及ぼしておくのが安全である。

医療機器ソフトウェア（SaMD）の場合の追加論点

生成したコードが医療機器そのもの、または医療機器の一部となる場合、要求は一段厳しくなる。

IEC 62304 ― ソフトウェアライフサイクルプロセス

医療機器ソフトウェアのライフサイクルを規定するのが IEC 62304:2006 であり、本稿執筆時点の現行は Amendment 1:2015 を統合した IEC 62304:2006+AMD1:2015（第1.1版）である。同規格は、ソフトウェアが故障した場合に生じうる危害の重篤度に応じて安全クラスA／B／Cを割り当て、クラスに応じて要求される開発・検証活動を規定する。

FDAのソフトウェア関連ガイダンス

市販前申請におけるソフトウェア文書の要求は、FDAの Content of Premarket Submissions for Device Software Functions に整理されている。AIを組み込んだ機器については、次の2文書が中心となる。

品質管理・コンプライアンス担当者が知っておくべき含意

AIコードへの品質保証の必要性

AIが生成したコードは、人間が書いたコードと同様に品質レビューの対象となる。むしろ、AIが高速に大量のコードを生成できるからこそ、それを検証するプロセスの設計が一層重要になる。

ISO 9001:2015 の品質マネジメントシステムの観点、および医療機器分野における ISO 13485:2016 の設計・開発要求の観点からは、AIによるコード生成プロセスを「設計・開発プロセス」の一部として位置づけ、適切なレビューと検証のステップを設けることが求められる。AIの能力が高まるほど、それを評価・管理する人間側の「力量（Competence）」の重要性は増すのであり、これは技術の進歩と品質管理の関係における普遍的な原則である。

実務チェックリスト

規制対応コードへの特別な配慮

医療機器ソフトウェアや製薬分野のシステム開発においては、21 CFR Part 11 や IEC 62304 といった規制要件への適合が必要となる。AIが生成したコードをこれらの規制対応プロセスに組み込む場合、バリデーション（妥当性確認）の証跡をどのように確保するかが課題となる。

現時点では、AI生成コードを規制対応の最終成果物として直接使用するための専用ガイダンスは、世界的にも発展途上にある。ただし本稿で見てきたとおり、専用ガイダンスがないことは「規制がない」ことを意味しない。既存のバリデーション要求・設計管理要求・記録管理要求は、コードの出所にかかわらずそのまま適用される。規制当局との継続的な対話と、業界標準の動向を注視する姿勢が求められる。

まとめ

Claudeのプログラミング能力がChatGPTより優れているかという問いに対する答えは、「2025年前半に公表された特定のベンチマーク・特定の測定条件・特定のバージョン同士の比較においては、Yesと言える根拠が公表されていた」という、限定を伴うものである。特に、大規模な文脈の正確な処理、指示への忠実性、コードの説明能力という三つの軸において、Claudeは競争優位を持つとされていた。

しかし、その根拠となったベンチマークは、本稿執筆時点で提供元自身によって「フロンティアのコーディング能力を測れていない」と評価されるに至っている。コンテキストウィンドウの数値上の差も、すでに解消している。技術指標に基づく優劣は、数か月単位で無効化されうる。

したがって、AIツールの選択は目的に応じた合理的な判断であるべきであり、特定のツールへの盲信は避けるべきである。いかなるAIが生成したコードであっても、それを評価・管理できる人間の専門性こそが、最終的な品質と安全性を支える根拠となる。