コレドウ
組織開発

AIで“作る”のは簡単になった。それでも破綻するのは、いつも運用だ

(更新: 曽良 竜太 (コレドウ代表取締役)
AIで“作る”のは簡単になった。それでも破綻するのは、いつも運用だ

この記事の要点

  • 同じAIに対して「嘘つき」と「すごい」が同居するのは、場面ごとに評価軸が変わっているから
  • 判断を任せると怒り、作業を任せると感動する。どちらも設計した人間の責任範囲にある
  • コードは動いた瞬間に正解に見えるが、壁打ちと同じレベルのミスが見えないまま埋まっている

最近ちょっと思うことがありまして。

AIに壁打ちしたり、相談したりしてる人が、

「AIは嘘ばっかりつく」

「ハルシネーション怖い」

「情報漏洩が」

みたいなことを言いながら、AIにキレてる場面、よく見かけます。

その一方で、同じ人がClaudeコードとかでちょっとしたツールを作れたりすると、

「AIすげえええええ!!!」

「使ってないやつマジで情弱ざまぁぁぁぁ!!」

みたいなテンションになる。

いや、あの、

その2つ、中身同じAIですから。

って毎回思うんですよね。

なぜこんなことが起きるのか

結論から言うと、AIの問題ではなくて、使い方と期待値の問題です。

もう少し分解すると、だいたい以下の3つに整理できます。

① 評価軸が場面ごとに変わっている

例えば、

壁打ち・相談 → 正しさを求める コード生成 → できるかどうかを求める

同じAIに対して、評価軸が全然違う。

壁打ちでちょっとズレたことを言われると「嘘つき!」になるし、

コードでちょっとでも動くものができると「天才!」になる。

でもこれ、AIの性能が変わったわけじゃなくて、 人間側の評価基準が変わってるだけなんですよね。

② 判断を任せると怒り、作業を任せると感動する

もう一つ面白いのがここで、

思考や判断を任せる → 間違うとキレる

作業を任せる → 成果が出ると感動する

という構造。

本来どちらも「ツール」なんですが、 前者だけ無意識に「意思決定者」として扱ってしまっている。

例えば、

市場分析を丸投げ → それっぽいけどズレてる →「AIは信用できない」

LPのコードを書かせる → とりあえず動く →「AIすごい」

これ、冷静に考えるとおかしくて、 どちらも「設計した人間の責任範囲」なんですよね。

③ 再現性の差を理解していない

壁打ちって、実はめちゃくちゃ再現性が低いです。

  • プロンプト
  • 文脈
  • 前提条件

この辺が少しズレるだけで、出てくるアウトプットは簡単に変わる。

一方でコード生成は、

  • 要件が明確
  • 入出力がはっきりしている
  • 構造がある

ので、比較的再現性が高い。

つまり、

たまたまうまくいった体験だけが強く記憶に残る

という状態が起きやすい。

その結果、

「AIすげえ!」と「AIクソ!」が同じ人の中に共存する。

でも、ここで一つ勘違いがある

ここまで読むと、

「壁打ちは不安定だけど、コードは正確」

みたいに思う人もいるんですが、それも違います。

同じくらいの頭脳のAIが動いている以上、間違いのレベルは本質的に同じです。

つまり、

壁打ちでズレるレベルのミスは、コードでも普通に起きている

ただ、それに気づいていないだけ。

コードで起きている“見えていないミス”

例えばよくあるのが、

  • 仕様を微妙に誤解したまま実装している
  • エッジケースが抜けている
  • エラーハンドリングが甘い
  • セキュリティ的に危ない書き方をしている

これ、全部「壁打ちでのズレ」と同じ種類の問題です。

ただし違うのは、

壁打ち → その場で違和感として気づきやすい

コード → とりあえず動くから気づかない

という点。

「動く=正しい」ではない

ここが一番危ないところで、

コードって動いた瞬間に「正解っぽく見える」んですよね。

でも実際には、

想定外の入力で壊れる データが壊れる 後から修正コストが爆発する

みたいな地雷が普通に埋まっている。

つまり、

壁打ちでキレている人は、コードでも同じレベルでミスを踏んでいる可能性が高い

ただ、それにまだ遭遇していないか、気づいていないだけ。

典型的な事例

ケース①:営業戦略をAIに丸投げする人

「うちのサービスの営業戦略考えて」

→ AIがそれっぽいことを言う → なんか浅い →「AIってこのレベルなんだよな…」

これ、そもそも入力が雑すぎる。

ケース②:GASでメール送信ツールを作る人

「このスプレッドシートからメール送るGAS書いて」

→ 普通に動く →「え、これ一瞬でできるのやばくない?」

→ 数週間後 → 例外ケースで送信事故 or スパム判定

ケース③:ちょっとしたプロダクトを作る人

Claudeコードとかで簡単なツールを作る

→ 動く →「もうエンジニアいらないじゃん!」

→ 後から仕様追加 → ぐちゃぐちゃで手がつけられない

じゃあどう扱うべきなのか

ここまでの話を踏まえると、整理はシンプルです。

① AIは「意思決定者」ではなく「実行装置」 判断は人間、実行はAI

② 評価軸を固定する 用途ごとに評価基準を決める

③ 再現性を設計する プロンプトを固定する 入力フォーマットを揃える 前提条件を明示する

④ 「動いたらOK」を捨てる テストする レビューする 想定外を潰す

結局なにが起きているか

ここまで全部まとめると、

AIを評価しているようで、実は自分の使い方を評価している

AIの性能に一貫性がないんじゃなくて、 使う側の評価基準と設計に一貫性がないだけなんですよね。

少しだけメタな話

これ、実は組織マネジメントとほぼ同じ構造です。

  • 評価基準が曖昧 → ブレる
  • 成果定義が曖昧 → 感情で判断する
  • プロセスが見えない → 過大評価 or 過小評価

AIに対して起きていることって、そのまま人に対しても起きる。

最後に

AIにキレるのも、AIに感動するのも別にいいんですが、 せめてそこは切り分けたほうがいい。

同じツールに対して、

  • 判断を任せて失敗してキレる
  • 作業を任せて成功して感動する
  • コードでは同じミスに気づかず感動する

この状態を繰り返している限り、 本質的には何も進んでいないので。

冷静に見るとシンプルで、

AIはずっと同じことをしている。変わっているのは、使っている側だけ

この認識に立てるかどうかで、 今後の使い方は結構変わるんじゃないかなと思っています。

ダウンロード

copy

目標設定でAIに何を任せて何を任せないかはAIで目標設定はどこまでできるのかに書きました。

関連記事