まず、要件と「良いアウトプット」の基準を決める
「エンジニアに仕組みを作ってもらったのですが、現場が使ってくれないんです」。相談に来るのは、たいていAI活用を進めているビジネス側の担当者です。
実際に使う人に聞くと、「使ってはみたけれど、結局あとで大きく直すので自分で作った方が早い」と。一方、エンジニアに聞けば、「正常に動いていますし、要件どおりに作っています」と返ってきます。これも、そのとおりです。
ツールの選定や社内データとの接続、権限の設定、安定して動かすための環境づくりは、経験のあるエンジニアが担当した方が速く、確実です。ビジネス側だけで進めようとすると、技術的な部分で止まってしまうことも少なくありません。
ただし、その前に決めるべきことがあります。どの業務を対象にするのか。AIに何を渡し、何を出してほしいのか。どこまでAIに任せ、どこから人が判断するのか。そして、どのような状態なら「実務で使える」と判断するのか。
ここは、その業務を知っているビジネス側が中心になって決める必要があります。曖昧なまま開発を始めると、技術的には正しく動いていても、現場が必要としているものとは違うものができあがります。
ただし、基準は最初からすべて書き切れない
もちろん、要件と基準を決めれば、それだけで実務に使えるものが完成するわけではありません。最初に言葉にできる基準は、できる限り決めておく。ただ、実際の仕事で求められる良し悪しを、最初からすべて仕様に書き切ることはできません。
その業務を何十回、何百回と経験してきた人の中には、言葉になっていない判断がたくさんあります。何を先に伝えるべきか。どこまで説明すると冗長なのか。どの数字には根拠が必要なのか。どんな表現なら相手に受け入れられるのか。
本人は自然に判断していても、条件として整理されていないものは、作る側からは見えません。営業の提案書を作るエージェントであれば、「顧客情報と商談メモをもとに、提案書のドラフトを作る」ところまでは仕様にできます。
ただ、課題と提案のどちらを先に見せるべきか、どの情報を削るべきか、相手が社内で説明しやすい流れになっているかまでは、実際に出してみないと分かりません。
AI活用における最初の要件は、完成形を定義するものというより、改善を始めるための仮説に近いと思っています。
出して、直して、また出す
だから、まず出してみる必要があります。
出てきたものを実際に使う人が見る。どこが違うのか、なぜそのままでは使えないのかを返す。その内容を、AIへの指示やチェック項目、参考例に反映して、もう一度出す。AIを業務に組み込むとき、この繰り返しは避けられません。
最初のアウトプットは完成品ではなく、要件や指示が正しかったかを確かめるための材料です。初稿を見て初めて、「ここまで指定しないと伝わらない」「この判断は自分の中にしかなかった」と気づくこともあります。
作ってから改善するのではなく、この改善までを含めて、最初の構築だと考えた方がうまくいきます。
直して終わりにしない
ここで大切なのは、出てきたアウトプットを直すだけで終わらないことです。
提案書のドラフトを人が書き直して提出すれば、その1本の仕事は片づきます。ただ、AIへの指示が変わっていなければ、次も同じところを直すことになります。
大事なのは、アウトプットを直すことではなく、次のアウトプットが良くなるように仕組みを直すことです。
順番を変えたのであれば、なぜその順番にしたのか。数字に根拠を加えたのであれば、どのような数字には出典が必要なのか。表現を変えたのであれば、元の表現の何が問題だったのか。
修正した箇所だけでなく、修正した理由までAIへの指示やチェック項目に戻していきます。
少し手間はかかりますが、一度戻した判断は次から繰り返し使えます。人が毎回同じ直しをしなくて済む状態をつくることが、AIを業務に組み込む意味だと思っています。
レビューするのは実際に使う人
アウトプットをレビューするのは、実際にその仕事で使う人です。
作った人は、正しく動いているか、指定された処理ができているかは確認できます。ただ、その内容が本番の場面で通用するかどうかまでは、実務を経験している人にしか判断できません。
提案書を作るエージェントなら、営業がドラフトを見て返します。
「この順番では、最後まで読んでもらえない」
「この数字は、根拠を添えないと商談で突っ込まれる」
「この提案は正しいけれど、相手の社内事情を考えると実行されない」
こうした判断を、次の出力に反映できる形にしていきます。
この改善を回すほど、初稿の質は上がります。最初の1本と、改善を重ねたあとの10本目では、出てくるものがまったく違います。
ところが、できあがった直後の初稿だけを見て、「これは実務では使えない」と判断してしまう会社も少なくありません。1本目を完成品として評価してしまうと、10本目にはたどり着けません。最初から完璧なものを期待するのではなく、誰がどのように育てていくかまで決めておく必要があります。
フェーズごとにエンジニアとビジネス側の役割を変える
では、エンジニアとビジネス側は、どのように役割を分ければよいのでしょうか。
GiftXでは、どちらか一方に任せるのではなくフェーズごとに中心となる人を変えています。
立ち上げ：エンジニア中心
利用するツールの選定、環境の構築、社内データとの接続、権限の設定などは、エンジニアが担当します。一度つくれば終わる部分も多いですが、ここを雑に進めると、セキュリティや運用上の問題があとから出てきます。
要件と品質基準：ビジネス側
どの業務に使うのか、何を入力し、何を出力するのか、どの状態なら使えるのかは、業務を知っている人が決めます。エンジニアには、実現方法や技術的な制約を確認してもらいます。
日々の運用と改善：ビジネス側
出てきたものを見て、どこが違うかを返し、指示やチェック項目に反映します。「また同じところを直している」と感じたら、それは人が頑張るのではなく、仕組みを変えるサインです。
構造的な作り替えと安全性の確認：一緒に
指示を追加しても改善しなくなったら、エージェントの構成やデータの渡し方自体を見直します。この段階では、ビジネス側だけで抱えず、エンジニアにも入ってもらいます。
外部サービスとの接続や権限の設定、APIキーの管理に問題がないかも、定期的に確認します。「そのAPIキーはどこに置いていますか」と聞かれて、すぐに答えられるか。そのくらいの確認からでも十分です。
正常に動いていると、問題がないように見えてしまいます。だからこそ、技術面は定期的にエンジニアにレビューしてもらうことが大切です。
エンジニアに任せきりにするのでも、ビジネス側だけで抱えるのでもありません。フェーズに応じて、それぞれの得意な役割を持つ。それが、現場で使われ続けるAI活用につながります。
まとめ
「うちはエンジニアに任せているから大丈夫」と思っているなら、開発の進捗だけでなく、出てきたものを誰が見ているかを確認してみてください。
その人の判断が、次のアウトプットに反映されているか。同じ修正が何度も繰り返されていないか。改善の流れが止まっているなら、AIはまだ業務の中で育っていません。
AIを育てられるのは、その仕事を繰り返し経験し、良し悪しを判断してきた人です。
AIを入れる目的は、その人の判断を不要にすることではありません。AIに作業を任せることで、人がより重要な判断に時間を使えるようにすることです。
そこまで来て、初めてAIを業務に入れた意味が出てきます。
AIが使えないのではなく、育てる役割と仕組みが、まだないだけかもしれません。
■セミナーのご案内
セミナーでは、AIエージェントを作って終わりにせず、実際の業務に組み込み、改善を回していく方法を、GiftXでの実例を交えながら紹介しています。
要件や品質基準をどう決めるのか、誰がアウトプットを確認し、どのようにAIを育てていくのか。自社のAI活用を次の段階に進めたい方は、ぜひご参加ください。
開催中のセミナー一覧
→https://ai.giftx.co.jp/seminars/
