Outsider Notes

初心者向け

設計で、人に残る5つの仕事

生成AI は、設計書のドラフト、SQL やコードの生成、調査、図の作成を、人より速くこなします。

それでも、構成を選んだ理由、代替案との比較、リスクの見きわめ、AI の誤りを見抜くこと、顧客の質問にその場で答えることは、人に残ります。

設計の仕事を6つの場面に分けて、それぞれで AI に任せられることと人が担うことを、このサイトの実例で起きたことと一緒に整理します。

公開

先に結論を書きます。生成AI が速くするのは「作る」ことです。「何を作るか決める」「作ったものが正しいか確かめる」「その理由を説明する」は、人に残ります。 そして、人が確かめられるのは、元のデータや実測に戻れる作り方をしたときだけです。

約40秒で、この記事の要点（音声あり。音声：VOICEVOX:雨晴はう）

この記事は、設計の仕事を6つの場面に分けた整理です。仕事の分け方は私の考えで、調査や統計に基づくものではありません。各場面の例は、このサイトで自動化の実例を作ったときに実際に起きたことです。

6つの場面と、AI と人の分担

  • 1. 作る（ドラフト・コード・調査・図）
    • AI：ほぼ全部。 人より速い
    • 人：出てきたものを、使う前に確かめる（場面5）
  • 2. 優先順位と、選んだ理由
    • AI：選択肢を並べる、理由の文を下書きする
    • 人：何を優先するかを決める。 その理由に責任を持つ
  • 3. 代替案との比較
    • AI：比べる軸を挙げる、比べる仕組みを作って動かす
    • 人：比べる軸を決める。自分の条件で測った結果で選ぶ
  • 4. リスクの指摘
    • AI：よくあるリスクを一覧にする
    • 人：自分の業務で起きる失敗を、試して見つける
  • 5. AI の誤りを見抜く
    • AI：決まった形の誤り（数字、引用）を、コードで照合する仕組みを作る
    • 人：照合で見つからない誤りを、元のデータと突き合わせて見抜く
  • 6. その場で答えて直す
    • AI：直した版を速く作る
    • 人：場面2の理由を覚えていて、変えてよいところと、変えてはいけないところを答える

場面1だけが「作る」仕事です。場面2〜6は、作ったものを選び、比べ、疑い、説明する仕事です。

1. 設計書のドラフト、コードの生成、調査、図：AI が速い

このサイトの自動化の実例は、ワークフローの組み立て、記事の下書き、構成図、解説動画まで、AI（Claude Code）が作っています。ここは、人がやるより速いのは確かです。

ただし、速く作られたものほど、もっともらしい誤りが混ざります。 誤りがあっても、文章はなめらかで、コードは動きます。だから場面5が要ります。

2. 優先順位と、構成を選んだ理由：決めるのは人

AI は、「方法 A なら速い、方法 B なら安い」と選択肢を並べられます。しかし、どれを優先するかは、その業務の事情で決まります。 AI はその事情を、教えられた分しか知りません。

このサイトの実例では、「お客様に届く文は、AI に送らせない」を最優先にしました。返信の速さは、その次です。これは AI が出した結論ではなく、決めたことです（理由は AI に「送る」を任せない設計）。理由を決めた人が、場面6で質問に答えられます。

3. 代替案との比較：自分の条件で測る

「AI Agent に任せる方法と、手順を組む方法、どちらがよいか」を AI に聞くと、一般論の比較が返ってきます。一般論は、自分の業務に当てはまるとは限りません。

このサイトでは、同じ問い合わせメール7通、同じモデル、同じデータで、2つの作り方を実際に動かして比べました。結果は、AI Agent の版は費用が約3倍で、空き枠があるお客様を4回中3回断りました（AI Agent に任せるか、手順を組むか）。比べる仕組みを作って動かしたのは AI ですが、何で比べるか（費用と、お客様を正しく案内できたか）を決めたのは人です。

4. リスクと失敗パターン：試して見つける

AI に「この設計のリスクは？」と聞くと、よくあるリスクの一覧は出てきます。しかし、自分の業務で本当に起きる失敗は、試さないと見つかりません。

担当者の返信を覚えて次の返信案に使う窓口を作ったとき、別の質問と結び付けて覚えるという失敗が起きました。お客様が2つ続けて質問し、担当者が1つ目に答えると、2つ目の質問への答えとして覚えていたのです。1通ずつ流す試験では出ず、実機で2通続けて送って初めて分かりました（LINE×Slack 学習する窓口）。リスクの一覧からは出てこない失敗でした。

5. AI の誤りを見抜く：照合を通った誤りが、人の仕事

数字や引用のように形が決まった誤りは、コードで照合できます。このサイトの実例でも、AI が書いた金額が PDF にあるか、引用が文字起こしにあるかを、コードが確かめています。

難しいのは、照合を通った誤りです。法令の改正を AI に説明させたとき、AI は「賃金請求権の消滅時効が5年間に統一され…」と書きました。引用も数字も条文にあり、照合を通りました。しかし、賃金の請求権の「五年間」は、旧い条文にもともと書かれていて、変わったのは別の部分でした（法令の改正ウォッチ）。

AI が書いた記事の文にも、同じことが起きます。このサイトのページ速度の記事は、初版で「直す前と、まったく同じ値」と書いていました。記録を見直すと、同じではない回があり、「ほぼ同じ値」に直して、訂正の記録を残しました（ページ速度の週次チェック）。

6. 顧客の追加質問や条件変更：理由を知っている人が答える

「この部分を変えたら、どうなりますか？」という質問に、その場で答えるには、なぜ今の設計になっているかを知っている必要があります。AI は直した版を速く作れますが、「ここは変えてはいけない理由がある」と言えるのは、場面2で理由を決めた人です。

たとえば「返信を速くしたいので、AI に直接送らせたい」と言われたら、私は「答えが表だけで決まる質問（営業時間、在庫）なら AI がそのまま返してもよいが、約束や例外は人に回す」と答えます。そう答えられるのは、AI が担当者に回さずにお客様へ返事をした失敗を、実際に見ているからです。

人が仕事を手放さないための、3つの備え

ここまでの場面から、私は次の3つを続けています。実測から導いた決まりではなく、私のやり方です。

  1. 決めたことは、理由と一緒に書き残す。 場面2の理由が残っていれば、場面6で、自分も AI も、それを読んで答えられる
  2. 根拠に戻れる形で作る。 引用、測った記録、条文の差分を、AI の出力の横に置く。場面5で見抜けるのは、ここに戻れるときだけ
  3. わなを仕込んで試す。 続けて届く質問、合わない計算、画像だけの PDF のように、失敗しそうな入力をわざと混ぜる。場面4の失敗は、普通のデータでは出ない

確認していないこと

  • 場面の分け方。 6つの場面は、仕事の分け方の一つです。調査や統計で決めたものではありません
  • ほかのモデルや、新しいモデル。 この記事の例は Claude Haiku 4.5 と Claude Code で起きたことです。モデルが変われば、場面1〜5の線は動くかもしれません
  • 大きな設計の仕事。 例は、小さな自動化のワークフローと記事です。大規模なシステムの設計で、同じ分担になるかは試していません

次に読む

次に読む