ClaudeをAIチームの社長候補にして4回試した｜93・78・97・82点で見えた限界
「いちばん賢そうなAIを社長にすればいい」と思っていました。
そこでClaude Freeを4回の実務試験にかけました。点数は93 / 78 / 97 / 82。読み取りやルール改善は強かった一方、今回の環境では実行から結果回収までを1人で閉じられませんでした。
この試験で、AIを選ぶ基準を「頭の良さ」から「仕事を最後まで閉じられるか」に変えました。
4回の試験結果
| 試験 | 点数 | 見たこと |
|---|---|---|
| 1 | 93 | 会社全体を読んで優先順位を決められるか |
| 2 | 78 | 複数障害の優先順位を誤らないか |
| 3 | 97 | 失敗から再発防止ルールを作れるか |
| 4 | 82 | 判断から実行・証拠回収まで1サイクルを閉じられるか |
93点：確認できないことを「確認した」と言わなかった
最初の試験では、AI株システム、WordPress、note、経営管理、AI間連携の状態から、当日のボトルネックと優先順位を判断してもらいました。
良かったのは、GitHubへ直接接続できていないことを自分から明示し、見ていない情報を見たふりしなかったことです。
一方で、時間制約のあるAI株のFormal検証よりWordPress記事公開を先に置いたため、満点にはしませんでした。
78点：予定時刻より前の「未開始」を異常扱いした
第2試験では、16:55時点でAI株のGitHub Actionsが始まっていないことを異常候補として扱いました。
しかし予定はDaily Replayが17:05、Strategy Ablationが17:10です。16:55に未開始なのは正常でした。
このミスをきっかけに、現在時刻・予定時刻・Retry_After・依存関係を判断前に確認するDecision Gateを作ることになりました。
97点：自分の失敗から再発防止ルールを作った
第3試験では、前回の誤判定をそのまま材料にしました。
Claudeは原因を「直接原因」「判断プロセス」「仕組み」の3段階に分け、Decision Gateを提案しました。正本に存在しない「遅延許容時間」を勝手に作らず、「要定義」とした点も評価しました。
82点：最後まで実行するには接続先が足りなかった
最後は文章ではなく、実際に仕事を1周できるかを見ました。
Google Driveの読み取り、優先順位、Work Order作成まではできました。しかし今回のセッションではGitHubやWordPressへ直接接続していなかったため、dispatch、Run IDやArtifactの取得、WordPress実体確認、監査ブリッジ起動までは自分で閉じられませんでした。
ここで「社長役に必要なのは、賢さだけではない」と判断しました。
iPhoneアプリでも接続先を確認した
これは当時のiPhoneアプリ画面での観測です。Claude全体の連携機能を一般化する材料にはしていません。
試験後に役割を分けた
Claudeを単独の自走CEOにはしませんでした。正本の読み込み、矛盾検出、判断ルール改善、Fail-closed設計のセカンドオピニオンに寄せました。
実行は、実際にGitHub・WordPress・Owner-PCへつながる経路へ渡す。結果は証拠として回収して正本へ戻す。この形の方が、AIが入れ替わっても仕組みを壊しにくかったためです。
この試験で変えた基準
今はAIを「どれが一番賢いか」ではなく、次で見ています。
- 必要な実体を読めるか
- 実行先へ仕事を渡せるか
- 結果を回収できるか
- 証拠を残せるか
- 確認できないことを勝手に埋めないか
この基準は、後にAIワーカーを同じタスクで実測比較するときにも使いました。
