自動化の境界線は「判断」にある——そしてその先へ

Epic Quest CTOの森本です。

判断に必要な材料を揃えるところまでは自動化する。判断自体は人間がやる。 これが今の方針。でも正直、これは既存のAIツールが全部やってることでもある。GitHub CopilotもCursorも、結局「AIが提案→人間が判断」という構造。

この記事では、今やってることと、その先に向かいたい方向、そしてAI時代に人間に本当に残るものは何かを考える。

今の自動化：材料を揃えて、判断は人間

Terraformを例にすると、こういう分担。

自動 – PRを出したらplan実行 – plan結果をPRにコメント – 差分の要約を生成

人間 – plan結果を見て「これで良いか」判断 – applyボタンを押す

判断材料はAIで自然言語に要約させてる。

## 変更サマリー

- EC2インスタンス `web` のインスタンスタイプを t3.medium → t3.large に変更
- セキュリティグループ `api-sg` にポート443のインバウンドルールを追加
- 削除されるリソースはありません

## 注意点

- インスタンスタイプの変更により、一時的なダウンタイムが発生します

これなら「何が起きるか」が一目でわかる。判断のスピードが上がる。

次のステップ：トリガーも自動にする

今考えてるのは、人間が指示を出す側から、承認する側に回ること。

従来

人間: 「このタスクやって」と指示
  ↓
AI: 作業
  ↓
人間: レビュー → 承認

次のステップ

AI: イシューやバックログを監視して、タスクを自動で拾う
  ↓
AI: 作業
  ↓
AI: 結果をチャット（Slack/Discord）に投稿
  ↓
人間: 通知を見て「OK」か「やり直し」を判断

人間は「やって」と言わなくていい。AIが勝手に動いて、結果だけ報告してくる。人間は見て承認するだけ。

さらにその先：バックログ生成もAIに

もっと言うと、バックログ自体もAIに作らせたい。

目指す形

人間: 「こういうの作りたい」とゴールを出す
AI: 要件に分解 → タスクに分解 → 作業 → 報告
人間: 承認

人間がやるのは、最初のゴール設定と、最後の承認だけ。

デメリットと対応

この方向に進むことのリスクも考えておく必要がある。

AIが暴走したとき止められるか

自動でタスクを拾って、自動で作業して、結果だけ出てくる。途中で変な方向に進んでても気づけない可能性がある。

対応：チェックポイントとやり取りを残す

完全に任せきりにしない。要所要所で「ここまでの方向性、合ってる？」と確認を入れる。

結果だけ出されても「なんでこうなった？」がわからないと判断しづらい。人間同士の仕事でも「結果だけ出しといて」って丸投げされたら不安になる。途中で方向性合ってるか確認したいし、想定と違う方向に進んでたら早めに軌道修正したい。AIも同じ。

やり取りを全部見る必要はない。ポイントは報告の粒度を設計すること。

方向性を決める場面 → やり取りする
決まった作業を進める場面 → 結果だけでいい
想定外のことが起きた場面 → 報告してもらう

あとはロールバック手段を必ず用意しておく。何かあったら戻せる状態にしておけば、致命傷にはならない。

判断材料が要約されすぎる

自然言語で要約されると読みやすい。でも要約の過程で重要な情報が落ちることもある。

対応：原文へのリンクを残す

要約だけで判断させない。「詳細はこちら」で原文に飛べるようにしておく。要約+詳細の2段構え。

若手が育たない

ある程度スキルがある人なら、AIにガンガン任せていい。判断する側に回って、生産性を上げればいい。

でも若手は違う。最初から判断だけやってたら、基礎スキルが身につかない。会社でも、現場で手を動かすフェーズを経て、判断する側に昇格していく。いきなりマネージャーにはなれない。

対応：育成フェーズでは意図的に手を動かす経験を積ませる

…と書いたものの、ここで一つ疑問が出てくる。

「判断」って何をしてるのか

ここまで「判断は人間がやる」と書いてきた。でも、よく考えると判断って何をしてるのか。

AIが「これでどう？」と出してくる。人間は「いいね」か「違う」と答える。

これ、判断というより照合じゃないか。

自分の頭の中にある「こういうのが欲しい」というイメージと、AIが出してきたものを照合してる。合ってたらOK、違ったら「こっち」と伝える。

だとすると、人間がやってることは： – イメージを持つこと – イメージと照合すること – 違ったら伝えること

「判断」という言葉は大げさで、実態はイメージとの照合。

イメージとは何か

ここで言う「イメージ」を定義しておく。

イメージ = ゴール、またはソリューション

「こういうものが欲しい」という完成形の像
「この問題をこう解決したい」という方向性

まだ言語化されてない、頭の中にある形。「なんかこんな感じ」というやつ。

このイメージがあるから、AIの出力を見て「合ってる」「違う」と言える。イメージがなかったら、AIが何を出してきても「いいんじゃない？」としか言えない。

イメージの伝え方は進化する

今、イメージを伝えるには言語化が必要。文章で書くか、会話で伝えるか、コードで表現するか。

でもこれ、将来変わる。

今：言語化して伝える – 「こういう機能が欲しい」と文章で書く – 設計書を作る – 会話で説明する

近い将来：複数案から選ぶだけ – 「こんな感じ」とざっくり伝える – AIが「これ？これ？これ？」と複数案を出す – 人間は「2番目が近い、でもここはこう」と選ぶ

最終形：イメージを直接入力 – 脳波インターフェース（BMI）などで、頭の中のイメージをそのまま伝える – 言語化すら不要になる

「複数案から選ぶ」段階で、既に言語化スキルの重要度は下がる。「うまく説明できないけど、こんな感じ」で伝わるようになる。

最終的に人間に残るもの

そう考えると、人間に最終的に残るのは「イメージを持つこと」だけ。

言語化 → AIが補完、または不要になる
照合 → AIが「これ合ってる？」と聞いてくれる
判断 → イメージとの照合なので、イメージがあれば自動的にできる

イメージを持つこと。「こういうのが欲しい」「こうしたい」という意思を持つこと。これだけは人間にしかできない。

AIはイメージを実現する手段をいくらでも出せる。でも「何を実現したいか」は人間が決めるしかない。

育成で本当に積むべきもの

だとすると、育成フェーズで積むべきは：

イメージを持つ訓練 – いろんなプロダクトに触れる – 「なぜこれは良いのか」を考える – 「自分だったらこうする」を考える

イメージの解像度を上げる訓練 – 良いもの / 悪いものを見分ける経験 – 「なぜこれはダメなのか」を言語化する経験（今はまだ必要） – 手を動かして「こうすると、こうなる」を体感する経験

手を動かすこと自体が目的じゃない。手を動かすことで、イメージの解像度を上げる。

「判断できる人」を育てるんじゃなくて、「イメージを持てる人」を育てる。

まとめ

今の自動化の境界線は「判断」にある。でも判断の正体はイメージとの照合。

向かいたい方向 – トリガーも自動化して、人間は承認する側へ – バックログ生成もAIに任せて、人間はゴールを出すだけに – イメージを伝える手段も進化する（言語化 → 選択 → 直接入力）

リスクへの対応 – 暴走リスク → チェックポイント、やり取りを残す、ロールバック手段 – 要約で情報が落ちる → 原文へのリンクを残す – 若手が育たない → イメージの解像度を上げる経験を積ませる

最終的に人間に残るもの – イメージを持つこと

言語化もコーディングも、イメージを伝える手段でしかない。その手段が進化しても、イメージを持つことだけは人間に残る。

「何を作りたいか」を持ってる人が、AIを使いこなせる。

質問や感想があれば、お問い合わせからどうぞ。