はじめに

数学の難問にAIを使う研究では、AIが出した答えをそのまま正しいとしているわけではありません。AIに候補を幅広く出させ、プログラムや形式的な検証手段で確かめ、最後は専門家が意味を判断します。

この考え方は、SESエンジニアの仕事にも応用できます。

例えば、障害の原因候補を出す、既存コードの構造を読む、テストの抜けを探す、設計書のリスクを洗い出すといった作業です。

ただし、AIを「正解を返す人」として扱うのは危険です。この記事では、FunSearchの候補生成と自動評価を参考に、筆者の実務上の整理として、AIを 仮説を出す人 として使い、テスト、ログ、公式資料、人によるレビューで確かめる方法を整理します。

先に結論

AIの強みは、正解を1回で出すことより、異なる仮説や反例を短時間で数多く出すこと
AIの提案は、テスト、静的解析、ログ、公式ドキュメントなどの 評価器 へ通す
同じAIに作成と最終判定の両方を任せず、別の観点と人のレビューを入れる
テストが通っても、前提とした要件が間違っていれば、実務上は不正解になる
SES現場では、顧客・所属会社のAI利用ルールを先に確認し、承認されたツールとデータだけを使う

前提

対象読者: 生成AIを障害調査、開発、レビューに使いたいSESエンジニア
使う環境: 顧客と所属会社が利用を許可したAIサービス、または個人の検証環境
扱わない範囲: 特定のAIモデルの性能比較、顧客情報を入力する方法、AIへの本番操作の全面委任
仕様確認日: 2026年8月18日

数学研究のAI活用から学べること

Google DeepMindのFunSearchは、LLMがプログラムの候補を作り、自動評価器が実行結果を確かめる構成です。評価の高い候補を次の世代に残し、何度も改良します。

AlphaEvolveも同様に、LLMの候補生成と自動評価を組み合わせ、精度や品質を数値化できる問題を改良しています。Google DeepMindは、データセンターのスケジューリングや行列積のアルゴリズムなどへの適用例を紹介しています。

これらの共通点を実務向けに単純化すると、次の形になります。

数学・アルゴリズム研究	SES・ソフトウェア開発
問題と評価条件を定義する	事象、要件、受け入れ条件を定義する
AIが解法の候補を生成する	AIが原因仮説、修正案、テスト案を生成する
反例を探す	境界値、異常系、失敗条件を探す
定理証明支援系や評価器で確かめる	テスト、リンター、静的解析、ログで確かめる
数学者が定式化と証明の意味を確認する	担当者、レビュアー、顧客が要件適合性を確認する

この対応表と以下のワークフローは、FunSearchやAlphaEvolveの公式分類ではありません。候補生成と評価を組み合わせる考え方を、筆者がSES実務向けに整理したものです。

SES現場向けの実行フロー

筆者は、AIを使う問題解決を次の7段階で整理しています。

1. 問題と成功条件を定義する

「動きません」だけでAIに聞くと、前提が足りないため、一般論の羅列になります。まず、次を整理します。

何が期待値か
実際に何が起きたか
どの条件で再現するか
影響範囲はどこまでか
解決と判定する条件は何か

2. AIに複数の仮説を出させる

1つの結論に誘導せず、可能性を並べさせます。各仮説に、確認に必要な証拠と、否定できる条件を付けます。

例

あなたは障害調査の補助者です。
次の情報だけを根拠に、原因仮説を優先順に5件まで出してください。

各仮説に次を付けてください。
- 根拠
- 追加で確認する情報
- 仮説を否定できる条件
- 影響の小さい確認手順

出力は「確認済みの事実」「仮説」「未確認事項」に分けてください。
情報が足りない場合は、推測で埋めずに質問してください。

3. 証拠を集める

AIの説明は、証拠ではありません。次のような一次情報で確かめます。

確認したいこと	優先する証拠
実際に起きたこと	ログ、メトリクス、トレース、操作履歴
仕様	顧客承認済みの要件、設計書、受け入れ条件
ソフトウェアの挙動	実装コード、テスト、変更履歴
外部サービスの仕様	公式ドキュメント、公式のリリースノート
過去の意思決定	チケット、プルリクエスト、議事録

4. 反例と失敗条件を探す

反例とは、「この説明は常に正しい」という主張を崩す例です。開発では、正常系で動く修正案に対して、次を探すことに近いです。

null、空文字、0、上限値などの境界値
タイムアウト、通信切断、一時的なエラー
権限のない利用者、セッション切れ
同時実行、再送、順序の入れ替わり
古いデータ、不正な入力、欠損した設定

例

次の修正案が失敗する条件を探してください。
賛成するレビューではなく、反例探索を優先してください。

観点:
- 境界値
- 異常系
- 権限
- 並行実行
- 可用性
- 後方互換性

出力:
1. 失敗条件
2. 再現手順
3. 期待結果
4. 自動テスト化できるか

GitHubの公式資料でも、GitHub Copilot Chatは境界値や異常系の単体テスト案を生成できる一方、すべてのシナリオを網羅するわけではなく、手動テストとコードレビューも必要と説明されています。

5. 評価器へ通す

SES現場で使える評価器は、特別なAIとは限りません。

単体テスト、結合テスト、E2Eテスト
リンター、型チェック、静的解析
依存パッケージの脆弱性検査
IaCの構文検査やポリシー検査
性能テスト、メトリクス比較
顧客と合意した受け入れ条件

例えば、AIがPythonの修正案を作った場合は、次のような検証スクリプトを通します。

ターミナル

#!/usr/bin/env bash
set -euo pipefail

# 基本的なコード品質と明らかなミスを確認する
ruff check .

# 正常系・異常系・境界値の回帰テストを実行する
pytest -q

# 代表的なPythonのセキュリティ問題を静的解析する
bandit -r app

この例のコマンドが成功しても、顧客の要件を満たしたことにはなりません。検査できるのは、あらかじめテストやルールに記述した範囲だけです。

6. 別観点でレビューする

作成時の会話をそのまま続けると、AIが自分の仮説を維持しようとすることがあります。新しい会話、別モデル、または人のレビュアーに、独立した情報として渡します。

例

以下は別の担当者が作成した修正案です。
作成者の意図に同意する必要はありません。

次の順にレビューしてください。
1. 要件と実装の不一致
2. 見逃された異常系
3. セキュリティと権限
4. 運用とロールバック
5. テストで検知できないリスク

各指摘に、対象箇所、失敗シナリオ、確認方法を付けてください。

7. 人が判断し、根拠を記録する

最終的な承認と責任は、AIではなく人が持ちます。次をチケットやプルリクエストに残します。

確認できた事実
採用した仮説と棄却した仮説
実行したテストと結果
残っているリスク
承認者と承認日時
ロールバック手順

現場別の使い方

障害調査

AIに最初から「原因は何ですか」と聞くのではなく、仮説の順位付けと、仮説を否定するための確認手順を作らせます。

例えば「アプリから外部APIへの接続がタイムアウトする」場合、DNS、ルート、プロキシ、TLS、接続先の遅延などを仮説として出し、現時点の証拠で優先順を付けます。

本番ログはそのまま外部AIへ貼らず、承認済みの環境で扱うか、識別子、IPアドレス、トークン、顧客名などを除いた最小限の再現情報にします。

既存コードの理解

AIにリポジトリ全体を一度に説明させるのではなく、次の順に分解します。

エントリーポイントと入出力を特定する
主要な呼び出し関係を図にする
外部サービスと副作用を洗い出す
既存テストが保証する範囲を確認する
AIの説明を実装コードと照合する

これにより、AIが存在しない呼び出し関係を作った場合も、早い段階で発見しやすくなります。

設計レビュー

AIにアーキテクチャの要約だけを依頼せず、次のような失敗シナリオを考えさせます。

1つのサービスが停止したらどうなるか
外部APIが遅いとき、リトライが増幅しないか
権限が広すぎないか
ログに個人情報や機密情報が出ないか
ロールバックでデータ不整合が起きないか
運用者が異常を発見できるか

テスト設計

AIに正常系のテストケース数を増やさせるだけでなく、次を分けて依頼します。

同値と見なせるデータのグループ
境界値の直前・直後
不正入力と権限エラー
依存先の遅延、切断、部分失敗
過去の不具合を再現する回帰テスト

仕様が曖昧なのに期待結果をAIに作らせると、AIはもっともらしい仕様を補ってしまいます。期待結果は、顧客と合意した要件や既存の正しい挙動から決めます。

手順書と運用ナレッジ

手順書をAIに読ませ、次の欠落を探させる使い方も有効です。

作業前の前提条件
各手順の成功判定
中断条件
異常時のエスカレーション先
ロールバック手順
実行結果の記録先

更新された手順書は、人が内容を承認したうえでリポジトリやドキュメント管理システムへ残します。AIの会話履歴だけに知識を閉じ込めません。

AIの利用可否を確認する聞き方

SESでは、所属会社が利用を許可していても、常駐先のルールで使えないことがあります。逆の場合もあるため、両方のルールを確認します。

「AIを使ってもいいですか」だけでは、回答する側も判断できません。次のように、ツール、目的、入力、出力の使い方を示します。

例

開発補助とテスト観点の洗い出しに生成AIを使うことを検討しています。
利用を想定しているのは、会社から提供された〇〇の業務用アカウントです。

次の内容を確認させてください。
- このツールを本案件で使用できるか
- 入力できる情報の範囲
- ソースコード、ログ、設計書を扱えるか
- 個人情報や機密情報の匿名化基準
- 生成物のレビューと保存ルール
- 利用履歴を記録する必要があるか

現時点では、本番情報の入力やAIによる本番操作は行わない前提です。

「法人契約のAI」「保護マークが表示されている」だけで、個別案件の情報を入力してよいとは判断できません。契約、テナント設定、データ保持、学習利用、顧客ルールを確認します。

AIへ入力しない情報

特に明示的な承認がない限り、次の情報を外部AIへ入力しません。

種類	例
認証情報	パスワード、APIキー、トークン、Cookie、秘密鍵
個人情報	氏名、メールアドレス、電話番号、顧客ID
機密情報	未公開の設計書、契約情報、内部URL、セキュリティ構成
本番データ	実在利用者のレコード、本番ログ、画面キャプチャ
未承認のコード	NDAの対象となるソースコード、社内リポジトリ全体

OWASPの2025年版LLM向けTop 10には、プロンプトインジェクション、機密情報の漏えい、不適切な出力処理、過剰な権限付与などが含まれます。AIの出力は、画面表示、SQL、シェル、APIなどへそのまま渡さず、通常の外部入力と同じように検証します。

NIST AI Risk Management Frameworkは、AIを設計、開発、利用、評価する際に、組織が信頼性とリスクを管理するための任意の枠組みです。この枠組みをSES現場に当てはめるなら、現場任せにせず、利用可能なツール、データ、承認者、モニタリングを組織のルールとして決める形になります。

AIに任せすぎないための停止条件

次の場合は、AIの自動実行を止め、人の判断へ切り替えます。

本番データの更新や削除を伴う
IAM、ファイアウォール、認証、暗号化の変更を伴う
コマンドの影響範囲を説明できない
仕様とAIの提案が矛盾している
テスト環境で再現できない
ロールバック手順がない
法務、個人情報、契約の判断が必要になる

GitHubも、AI生成コードのレビューとテストを求めています。生成コードは不正確であったり、脆弱性を含んだりする可能性があるため、特にセキュリティ上重要なシステムでは十分な確認が必要です。

数学と同じく「問題の定義」が最も難しい

形式的な証明ツールは、入力された命題に対する証明を検査できます。しかし、その命題が本当に証明したかった内容かどうかまで、自動的に保証するわけではありません。

開発も同じです。テストがすべて通っても、テストそのものが誤った要件を表していれば、顧客が求める動作にはなりません。

AIが進化するほど、エンジニアには次の力が必要です。

曖昧な要望を検証可能な条件へ分ける力
事実と仮説を分ける力
主張を崩す反例を考える力
安全な評価方法を作る力
出力を採用するか判断し、説明する力

AI時代にエンジニアが不要になるのではなく、 問題と評価条件を作れるエンジニアの価値が上がる と考えています。

参考・確認先

FunSearch: Making new discoveries in mathematical sciences using Large Language Models - Google DeepMind
AlphaEvolve: A Gemini-powered coding agent for designing advanced algorithms - Google DeepMind
Responsible use of GitHub Copilot Chat - GitHub Docs
AI Risk Management Framework - NIST
2025 Top 10 Risk & Mitigations for LLMs and Gen AI Apps - OWASP Gen AI Security Project
筆者独自に追加した内容: 数学研究の候補生成と自動評価の考え方を、SESの障害調査、コード理解、設計レビュー、テスト設計へ応用する手順とプロンプト
仕様確認日: 2026年8月18日

まとめ

AIは正解を無条件に返す存在ではなく、仮説、修正案、反例を作る補助者として使う
AIの提案は、ログ、公式資料、テスト、静的解析、独立レビューで確かめる
反例探索を依頼すると、正常系だけでは見落としやすいリスクを発見しやすい
テストが通ることと、顧客の要件に合うことは分けて確認する
SES現場では、利用するAI、目的、入力範囲、保存方法を事前に確認する

おわりに

まずは、日々の障害調査やレビューで1つの結論を聞くのではなく、「仮説を3件出す」「反例を探す」「否定条件を付ける」という使い方から試すと、AIを実務の考える道具に変えられます。

Wealthy Designでは、AIに判断を丸投げせず、エンジニアが検証と説明に責任を持てる開発と人材育成に取り組んでいます。会社の取り組みや採用情報は、会社サイトにまとめています。