こんにちは、エスワイシステム関東の中平です。
AI開発の話をすると、たいてい「コードを書かせる」ところから想像されます。
でも僕の最初は、コードではなく、要件定義や設計をAIと一緒にやるところからでした。
これまで、AIとどう仕事をしてきたか
まだ「コンテキスト」という言葉が、今ほど浸透していなかった頃です。
用語として知っていたというより、感覚で掴んで、そう言っていた。
いまの状況や、自分の立場で分かる前提を渡すほど、出てくるアウトプットがイメージに近づく。
だから渡せるものはできるだけ乗せて進めていました。
結果、AIと一緒に作るアウトプットは、そこそこの質になっていた記憶があります。
しんどかったのは、そのあとです。
AIの出力をパワポやExcelにまとめながら、脳内でずっとレビューし続ける。ハルシネーションも多い。
指摘が多いと、直してない部分も気づかないうちに変わる。
毎回一から読み直すような感覚で、“レビューが、めちゃくちゃ面倒だった”。
なので当時のやり方はこうでした。
構想や組み立ては、ある程度まで僕とAIで作る。それを人間のコーディングに通す。
コードにする過程で、ふわっとした嘘やズレがあぶり出される——そんな使い方です。
いま振り返ると、あれは「AIに書かせて速くする」というより、“人が検証できる形に落とすまでが、仕事の本体”だったんだと思います。
もちろん当時、メンバーもAIでコードを書いていました。
ただ強く記憶に残っているのは、“人によって品質のブレが大きかった”ことです。
仕様をちゃんと解釈できる人は、プロンプトも上手くて、出てくるプログラムの質も高い。
仕様を表面的に受け取る人は、どうしても品質が乗らない。
つまりAIは、理解している人の手を加速し、理解が浅い人の「わかったつもり」も加速してしまう。どこかで聞いた言葉に近い。
“AIは強い人をより強くし、弱い人をより弱くする”。
厄介だったのは、弱い側が何も出せない、ではなかったことです。
むしろ一見、形になっている。それっぽく動く。画面もある。本人もできた気でいる。なのに中身はつぎはぎで無茶苦茶。
レビューすると、仕様の解釈の浅さが、そのままつぎはぎの跡になって出てきます。
道具の差というより、“仕様を読む力の差が、そのまま成果の差になっていた”。
この経験が、あとで「プロンプト集を配れば、プロジェクトは回る」とは思えなくなった原点です。
（前にもコラムでAIの話は書きました。でも、やり方が一段深いところに来たので、今日はその続きを書きます。）
仕事を型に落とす
いまの僕の仕事の大半は、コードをきれいに書き上げることじゃありません。
何を直すか決める、調べて指示を書く、レビューしてもらう、実装に渡す、試験して結果を残す、うまくいかなければ指示に戻る——
この流れです。
コードを書かせるだけだと、このうち一部しか速くなりません。
だから「速くなったのに、仕事は減らない」。
なので今は、“繰り返している仕事そのものを、AIが迷わず走れる形に落とす”ことに力を入れています。
手順や判断の置き場、やっていいこと・ダメなこと、終わったと言える条件。
人によってブレていた「仕様の読み方」を、毎回説明し直すのではなく型として残す。
プロンプトを一枚配る、ではありません。
順番は、Goal → Loop → AI
大事なのは、この順番です。
-
Goal
誰にとって、どんな現実が、どうなれば成功か
-
Loop
そのために繰り返している仕事は何か
-
AI
そのループのどこを、どのように、AIに任せるか
逆から入ると危ない。
「とりあえずAI」「とりあえずコードを書かせる」「動いたから成功」——道具が主役になって、行き先が曖昧なままレールだけ増えます。
AI駆動開発とは、AIにコードを書かせることではない。
AIが仕事を進められるように、仕事そのものを構造化することである。
AIは線路を敷いて走る。行き先を決めるのは人。
この分担を先に決めないと、また「形だけ・つぎはぎ」が増えます。
「動いた」を成功にしない
だから、いきなり「AI駆動のPoCやりましょう」と言いたくないんです。
危ないのは、だいたいこの順番です。
ツールを入れる、サンプルでコードを書かせる、画面が動く、「成功でした」。
でも現場の仕事は、その先にレビューも試験も引き継ぎも、やり直しもある...。
画面が動いた、は成果物です。
困りごとが減った、が成果です。
動いたデモは成果物にはなる。でも、利用者の困りごとが減ったかは別の話です。
だから入り口は、完成パッケージを先に売るより、
「いま何を成功させたいか」「何を繰り返しているか」を一緒に聞くところから、と思っています。
使わない、という結論が出てもいい。それも仕事のうちです。
おわりに
最初の頃の僕は、AIと要件や設計を組み立て、人のコーディングであぶり出し、それでもレビューに消耗していました。
いまは、コードより手前の「仕事の型」に手を入れ始めています。
楽になったか、と聞かれたら——正直、まだ道半ばです。
いや、僕だけは楽になったかも。
でも現場の仕事全体が速くなったかと聞かれると、まだ違う。
ただ、「プロンプトを配れば回る」とも、「コードが速くなれば開発が速くなる」とも、もう思っていません。
行き先を決めるのは人。道具はあとから、でいい。
著者情報
中平 裕貴（Yuki Nakahira）
株式会社エスワイシステム 関東事業本部
関東3SEシステム事業部 社会情報インフラ部
エバンジェリスト
『技術 × 事業戦略 × 組織運営をつなぐ実務家』
エンジニア・経営・営業を経て、技術とビジネスの橋渡し役を担ってきた。
現在は AI駆動開発を「コードを書かせること」ではなく、Goal → Loop → AI の順で仕事そのものを型にする実践として進めている。
仕事を構造化し、現場に価値が残る形で届ける。
🛠 技術領域
アプリ開発、クラウド、データ分析、AI、
📈 事業・営業経験
SI事業の拡大、プロジェクトマネジメント、アジャイル
🏗 組織マネジメント
リーダー育成、組織改革、チームビルディング
📩 お問い合わせ・お仕事のご相談はこちらから↓
