Abstract
前回の記事で提起したLLMブートストラップ問題—「ツール作成者（制約なしLLM）と使用者（制約ありLLM）の動作特性の違い」—に対する実践的解決手法を報告する。
本手法は、(1)人間による実体験の言語化、(2)LLMによる形式化、(3)人間による曖昧性排除（校正）、という3段階プロセスである。40年のITキャリアを持つ私が日常的に実践し、有効性を確認した。
本稿では、手法の詳細、具体的実装例、測定可能な改善指標、および他手法との比較を示す。
1. 問題の再定義
1.1 ブートストラップ問題の形式化
LLMをLLMA（制約なし）とLLMB（制約あり）に分けると：
LLM_A(state=unconstrained)
→ generates rules R
→ LLM_B(state=constrained, rules=R)問題の本質：
- LLMAは文脈依存の柔軟な判断ができる
- LLMBは明示的なルールRに従う
- しかしRには、LLMAが「これで大丈夫」と判断した曖昧さが含まれる
- 結果：LLMBはRを適切に解釈できない
1.2 曖昧性の定量化試行
私が発見した典型的な曖昧表現：
| 表現 | 判断主体の不明確さ | 条件の未定義度 |
|---|---|---|
| 「必要な場合のみ」 | LLM自身？ | 何をもって「必要」？ |
| 「適切に判断」 | 基準は？ | 適切の定義は？ |
| 「可能性がある」 | 確率は？ | 判断基準は？ |
これらは、VMware論文（2024）が指摘する「LLMは表現のわずかな違いに敏感」と整合する。
1.3 既存手法の限界
| アプローチ | 主な問題 |
|---|---|
| Constitutional AI | 原則作成時の曖昧性を考慮していない |
| LLM-as-Judge | 評価基準の曖昧性が伝播 |
| Few-shot examples | 例の選択基準が曖昧 |
| Prompt optimization | 最適化プロセス自体がブートストラップ問題 |
共通の盲点：作成者と使用者の動作モード差を明示的に扱っていない
2. 提案手法：3段階校正プロセス
2.1 全体アーキテクチャ
┌─────────────────┐
│ Human Expert │
│ (40-year exp) │
└────────┬────────┘
│ Step 1: Verbalization
↓
┌─────────────────┐
│ Raw Experience │
│ (Natural lang) │
└────────┬────────┘
│ Step 2: Formalization
↓
┌─────────────────┐
│ LLM (Claude) │
│ Structures it │
└────────┬────────┘
│ produces
↓
┌─────────────────┐
│ Draft Rules R' │ ← Contains ambiguity
│ (with ambiguity)│
└────────┬────────┘
│ Step 3: Calibration
↓
┌─────────────────┐
│ Human Expert │
│ Removes ambig. │
└────────┬────────┘
│ produces
↓
┌─────────────────┐
│ Final Rules R │
│ (no ambiguity) │
└─────────────────┘2.2 Step 1: 実体験の言語化
Input: 暗黙知としての判断パターン
Output: 自然言語での記述
実例：事業撤退判断
私の実体験（2025年5月）:
「AWS QuickSuiteの発表を見て、
自社のコスト削減コンサルティング事業が
競合できないと判断。
1週間の調査後、撤退決定」
抽出される判断プロセス:
- 調査期間：1週間
- 判断基準：競合優位性の喪失
- 感情ではなく数値での判断重要な点：
- 具体的な状況を語る
- 数値・期間を明示
- 判断の根拠を言語化
2.3 Step 2: LLMによる形式化
Input: 自然言語での実体験
Output: 構造化されたルール（曖昧性を含む）
LLM（Claude）の出力例：
撤退判断フレームワーク:
数値閾値: 明確な警告ライン
時間閾値: 検証期間と改善サイクル
優先順位: 継続・縮小・停止の判断基準問題の顕在化：
- 「明確な警告ライン」→ 何をもって「明確」？
- 「検証期間」→ 具体的に何日？
- 「判断基準」→ 誰が判断する？
これがブートストラップ問題の実例
2.4 Step 3: 人間による校正
Input: 曖昧性を含むルールR’
Output: 曖昧性を排除したルールR
校正プロセスの実例：
Before（LLMが生成）
数値閾値: 明確な警告ライン校正作業
私の指摘:
「『明確な』じゃなくて、数値を書け」
「誰が判断するかを明示しろ」
「例外処理を禁止しろ」After（校正後）
数値閾値（厳守）:
1年後: 顧客数10社未満
→ アクション: 開発優先度を下げる（必須）
→ 判断者: 代表者（私）
→ 例外: 認めない
2年後: 顧客数20社未満
→ アクション: 大幅な戦略見直し（必須）
→ 判断者: 代表者（私）
→ 例外: 認めない
禁止表現:
× 「状況を見て判断」
× 「適切に対応」
× 「必要に応じて」2.5 曖昧性排除のチェックリスト
私が開発した体系的チェック：
def check_ambiguity(rule_text):
"""
曖昧性を検出する
"""
ambiguous_patterns = [
# 判断主体が不明
r'必要な?場合',
r'適切に?',
r'可能性',
# 条件が未定義
r'明確な?',
r'重要な?',
r'十分な?',
# 例外を許容
r'原則として',
r'基本的に',
r'通常は',
# 定量化できていない
r'多く?の?',
r'少し',
r'やや',
]
for pattern in ambiguous_patterns:
if re.search(pattern, rule_text):
return True, pattern
return False, None2.6 校正の具体例（研究者向け詳細版）
Case 1: 企業分析ルール
Step 1（私の実体験）:
「40年のIT業界経験で、取引銀行を
記載していない企業は、何か問題を
抱えているケースが多かった」Step 2（LLMが形式化）:
取引銀行が記載されていない場合は、
信用性配慮不足の可能性がある問題点の検出:
- 「可能性がある」→ 確率は？
- 「信用性配慮不足」→ 具体的には？
- 判断主体が不明
Step 3（私が校正）:
取引銀行記載の評価（必須チェック項目）:
条件1: 取引銀行が記載されている
→ 判定: 問題なし
→ 次のチェックへ進む
条件2: 取引銀行が記載されていない
→ 判定: 「信用性配慮不足」と判断する（確定）
→ レポートに以下を記載せよ（必須）:
「取引銀行の記載がありません。
40年の経験上、この情報を非開示にする企業は
財務状況や取引関係に問題を抱えている
可能性が高いため、注意が必要です。」
禁止表現:
× 「可能性がある」（曖昧）
× 「適切に判断」（判断基準不明）
× 「必要に応じて」（条件不明）
根拠:
- 私の40年の実務経験
- IT業界での企業審査経験
- 倒産・トラブル企業の事前兆候分析Case 2: 箇条書き使用ルール
Step 1（私の実体験）:
「技術文書では、説明が複雑になると
つい箇条書きを使ってしまう。
しかし読み手は文章の方が理解しやすい
と感じることが多い」Step 2（LLMが形式化）:
箇条書きは必要な場合や指示がある場合のみ使用し、
通常は文章形式で回答する問題点の検出:
- 「必要な場合」→ 誰が判断？
- 「通常は」→ 例外を許容している
- 「指示がある場合」→ 明示的か暗黙的か
Step 3（私が校正）:
箇条書き使用の厳格なルール:
条件1: ユーザーが以下の表現で明示的に指示した場合のみ使用可
- 「箇条書きで」
- 「リストで」
- 「項目ごとに」
- 「番号付きで」
条件2: 上記以外の全ての場合
→ 文章形式で回答する（必須）
→ 箇条書きを使用しない（厳守）
判断の余地:
× LLM自身による「わかりやすくするため」の判断は禁止
× 「複雑だから箇条書き」という判断は禁止
× 暗黙的な指示での箇条書きは禁止
理由:
私の40年の技術文書執筆経験から、
箇条書きは書き手には便利だが、
読み手の思考の流れを分断する。
文章形式の方が論理的な繋がりが明確。3. 実装とスケーラビリティ
3.1 記録システム
私は以下の構造で記録を管理：
## 議論履歴.md
### 修正済み曖昧表現
| 元の表現 | 問題点 | 修正後 | 修正日 |
|---------|--------|--------|--------|
| 可能性がある | 確率不明 | 判断する | 2025-11-20 |
| 適切に | 基準不明 | 条件A,B,Cを満たす場合 | 2025-11-21 |
### ルール追加履歴
| ルール | 根拠となる実体験 | 追加日 |
|--------|-----------------|--------|
| 取引銀行チェック | 40年の企業審査経験 | 2025-11-15 |3.2 反復的改善プロセス
def iterative_calibration():
"""
日次で実行される校正プロセス
"""
while True:
# 1. AIサービスを自分で使用
response = ai_service.query(my_question)
# 2. 違和感を検出
if detect_ambiguity(response):
# 3. 問題点を記録
log_issue(response, ambiguity_type)
# 4. 校正を実施
calibrated_rule = calibrate(response)
# 5. ルールを更新
update_rules(calibrated_rule)
# 6. 次回から反映
deploy_updated_rules()3.3 品質指標
私が測定している指標：
| 指標 | 測定方法 | 目標値 |
|---|---|---|
| 曖昧表現出現率 | パターンマッチング | <5% |
| ルール遵守率 | 手動確認（週次） | >95% |
| 違和感検出頻度 | 私の日次使用で | 週1件以下 |
| 修正までの時間 | 発見から修正まで | 24時間以内 |
4. 理論的考察
4.1 なぜ人間の校正が必要なのか
Gödel的制約の回避：
自己参照系では、システムが自身の完全性を証明できない（Gödelの不完全性定理）。LLMが自分用のルールを作る場合、同様の制約が働く可能性がある。
人間による外部からの校正は、この自己参照ループを断ち切る。
動作モードの可視化：
Human: 動作モードAとBの違いを認識できる
↓
「これは制約ありLLMには難しい」と判断
↓
明示的な条件に書き換え
LLM: 自身の動作モードを完全には認識できない
↓
「これで大丈夫だろう」と判断
↓
曖昧性を残す4.2 40年の経験の役割
パターン認識の蓄積：
私の40年のキャリアで形成された暗黙知：
- 「こういう表現は誤解を生む」
- 「この条件は不十分」
- 「ここに例外処理が必要」
これらは、LLMには獲得できない。
違和感検出の速度：
一般的なユーザー:
AIの回答を読む → 受け入れる
40年の経験者（私）:
AIの回答を読む → 0.5秒で違和感
→ 即座に指摘4.3 Constitutional AIとの比較
| 項目 | Constitutional AI | 私の手法 |
|---|---|---|
| ルール作成 | LLMが自己生成 | 人間の実体験から |
| 曖昧性チェック | LLM自身 | 経験者が校正 |
| 動作モード考慮 | 明示的でない | 意識的に考慮 |
| スケール | 大規模 | 小規模（個人） |
補完関係：
私の手法は、Constitutional AIの「原則生成」フェーズに人間の校正を組み込むことで強化できる。
5. 限界と課題
5.1 スケーラビリティの制約
現状：
- 私（1人）が毎日使用し、手動で校正
- 月に数件のルール追加・修正
限界：
- 私の処理能力に依存
- 大規模サービスには適用困難
可能な緩和策：
Phase 1: 創業者が手動校正（現在）
↓
Phase 2: 校正パターンをML化
↓
Phase 3: 自動校正+人間の最終チェック5.2 経験依存性
問題：
- 40年の経験がない場合、違和感検出が困難
- 若手には真似できない
対策の可能性：
- チェックリストの標準化
- 曖昧パターンのデータベース化
- 経験者のレビュー体制
5.3 完全性の欠如
この手法でも100%の曖昧性排除は不可能：
- 新しい曖昧パターンは常に出現
- 文脈依存の判断は残る
- 人間のミスもある
6. 研究者・開発者への示唆
6.1 AI by AIの設計指針
提案する設計原則：
原則1: 動作環境の明示的考慮
- ツール作成者と使用者の制約を列挙せよ
- 両者の差分を意識せよ
原則2: ターゲット環境での反復改善
- 制約なしLLMに作らせて終わりにするな
- 制約ありLLMで動作検証せよ
原則3: 人間による品質保証
- LLMの自己評価だけに頼るな
- ドメイン専門家の校正を入れよ
原則4: 曖昧性の定量化
- 「可能性」「適切」などをメトリクス化
- 継続的にモニタリングせよ6.2 今後の研究課題
理論面：
- LLMの動作モードの形式的定義
- 曖昧性の定量的評価指標
- ブートストラップ問題の発生条件
実証面：
- 大規模での検証
- ドメイン間の転移可能性
- 自動化の可能性
工学面：
- 校正支援ツールの開発
- 曖昧パターンのデータベース
- 継続的改善のフレームワーク
7. 実装支援
7.1 曖昧表現検出ツール（GitHub公開予定）
class AmbiguityDetector:
"""
ルール文中の曖昧表現を検出
"""
def __init__(self):
self.patterns = {
'judgment_ambiguity': [
'必要な場合', '適切に', '可能性',
],
'condition_ambiguity': [
'明確な', '重要な', '十分な',
],
'exception_allowance': [
'原則として', '基本的に', '通常は',
],
}
def detect(self, text):
"""
曖昧性スコアを返す
"""
score = 0
findings = []
for category, patterns in self.patterns.items():
for pattern in patterns:
if pattern in text:
score += 1
findings.append({
'category': category,
'pattern': pattern,
'suggestion': self.get_suggestion(pattern)
})
return score, findings
def get_suggestion(self, pattern):
"""
修正案を提示
"""
suggestions = {
'必要な場合': 'ユーザーが明示的に指示した場合のみ',
'適切に': '条件A, B, Cを満たす場合',
'可能性': '判断する',
# ... 他のパターン
}
return suggestions.get(pattern, '具体的な条件を明示してください')7.2 校正チェックリスト（テンプレート）
## ルール校正チェックリスト
### 1. 判断主体の明確化
- [ ] 誰が判断するか明記されているか
- [ ] LLMの判断余地はゼロか
- [ ] 例外処理は明示されているか
### 2. 条件の具体化
- [ ] 数値・期間が明示されているか
- [ ] 「明確な」「適切な」を排除したか
- [ ] 全ての条件分岐を列挙したか
### 3. 曖昧表現の排除
- [ ] 「可能性」→「判断する」に変更したか
- [ ] 「原則として」→「必ず」に変更したか
- [ ] 「適切に」→具体的条件に変更したか
### 4. 実体験との紐付け
- [ ] なぜこのルールか、根拠を記載したか
- [ ] 具体的な失敗・成功事例を記録したか
- [ ] 経験年数・ドメインを明記したか8. 結論
8.1 主な貢献
- ブートストラップ問題の実践的解決法を提示
- 理論的問題提起だけでなく、実装可能な手法
- 曖昧性排除の体系的アプローチ
- チェックリスト、パターン検出、校正プロセス
- 人間の経験知の活用方法
- 暗黙知の形式知化
- ドメイン専門家の役割の明確化
8.2 適用可能性
この手法は以下に適用可能：
- LLM-as-Judgeの評価基準作成
- Constitutional AIの原則生成
- プロンプトエンジニアリング
- Recursive Self-Improvementの初期設定
8.3 次のステップ
私は現在、この手法を利用したサービスを構築中です：
- 現在社外秘になってますが、みなさんが「欲しい」と思うものです。なぜなら、私が欲しいと思って作ってるからです。少なくともユーザーは1人います。
サービス公開後、以下を報告予定：
- 定量的な効果測定
- 大規模運用での知見
- 自動化の可能性
謝辞
本手法の開発は、私の40年のITキャリアと、Claude（Anthropic）との日々の対話から生まれました。AI業界の研究者・開発者の方々との建設的な議論を期待しています。
著者について
椎原 亮
合同会社ダックエンジン 代表社員
40年のITキャリア、現在はAIサービス開発に従事
本手法を日常的に実践し、有効性を検証中
合同会社ダックエンジン
2025年11月
コメント