AIエージェントが使い物にならない理由。
問題はAIではなく「ハーネス」にあるかもしれない。

AIに仕事を任せたのに、ミスばかりする。何度教えても同じ失敗を繰り返す。指示したことを忘れる。勝手な判断をする。

こういう経験をしている人は、結構多いのではないでしょうか。

私もAIエージェントを使い始めた頃は、似たような問題に何度もぶつかりました。

そのたびに指示を細かくしたり、ルールを追加したり、AIに原因を考えさせたりしていました。

ところが、AIを使い込むうちに、問題の多くはAIの頭の良し悪しではなく、AIが仕事をするための環境にあると考えるようになりました。

最近、AIの世界でよく聞く「ハーネス」という言葉です。

以前、ほかの会社のAIエージェントを調べさせてもらった話を書きました（AIがミスばかりする会社と、安定して動く会社。その違いはAIの能力ではなかった）。今回はその逆で、自分の会社で実際に踏んだほうの話です。ここに出てくる失敗は、全部こちらでやらかしたものです。

そもそもハーネスとは何か？

簡単に言えば、AIが会社の仕事を正しく、継続して行うための仕組み全体です。

例えば、新入社員が入社したとします。

その社員が非常に優秀な人だったとしても、

• 会社の仕事内容を知らない
• 商品や顧客の情報を見られない
• 自分の担当業務が決まっていない
• 何を勝手に決めてよいのか分からない
• 過去にどんな仕事をしたのか記録がない
• 困ったときに誰に相談すればよいのか分からない

こんな環境では、まともに仕事ができません。

AIも同じです。

どれだけ高性能なAIを使っていても、仕事をするための情報やルール、仕組みがなければ、その能力を十分に発揮できません。

この仕事環境を整えることが、ハーネスの役割です。

なお、ハーネスという言葉には技術的にさまざまな使い方がありますが、この記事では、AIエージェントを会社で継続運用するための仕組み全体という意味で使います。

1. AIが同じミスを何度も繰り返す

よくあるのが、AIが間違えたので指摘したところ、その場では謝罪して修正するものの、数日後にまた同じ間違いをするという問題です。

例えば、商品説明文の作成を任せていたとします。

AIが勝手に商品の特徴を付け加えたので、

と指示します。

AIは理解したと回答します。

ところが、翌日別の商品を任せると、また存在しない特徴を書いてしまう。

なぜでしょうか。

AIに注意したことと、再発防止の仕組みができたことは、まったく別だからです。

会話の中で理解しても、その内容が次回の仕事に引き継がれるとは限りません。

さらに、ルールとして保存していたとしても、そのルールが実際の仕事で読み込まれていなければ意味がありません。

必要なのは、例えば次のような仕組みです。

• 確認できない商品情報は書かないというルールを保存する
• 商品説明を作る際に、そのルールを必ず参照する
• 商品データに存在しない特徴が書かれていないか検査する
• ミスがあれば、原因と修正内容を記録する

こうして初めて、同じミスを繰り返しにくくなります。

当社でやったこと：「完了」の条件を変えた

当社で効いたのは、ルールを足すことではなく、何をもって「直した」と数えるかを変えたことでした。

私が受ける報告で一番多かった型が、「この前実装したものが、実際は稼働していませんでした」です。

そこで、仕様をひとつ変えたら、

• 効いていれば通る検査のコマンドを用意する
• その検査を一覧表に1行登録する
• 毎朝それを自動で回す

この3つがそろうまで完了に数えない、というルールに変えました。

一覧表を作って、過去に実装したものを数十件さかのぼって登録してみたところ、書類の上では「稼働中」なのに、実際には止まっていたものが3件出てきました。

そのうち1本は、設置してから一度も動いていませんでした。設定ファイルの書き方がわずかに違っていて、起動の瞬間に一度だけエラーが出たきり、あとは永久に無言だったのです。

「ルールに書いた」でも「設置した」でもなく、「動いていることを機械が毎日確かめている」。ここまで来て、ようやく再発防止になります。

AIに何度も注意している会社は、AIの理解力を疑う前に、その注意が次の仕事に反映される仕組みがあるか確認したほうがよいと思います。

2. AI担当者ごとに言うことが違う

複数のAIエージェントを使い始めると、次の問題が出てきます。

AI担当者Aは「広告費を増やしましょう」と言う。

AI担当者Bは「広告費を削減しましょう」と言う。

同じ会社の数字を見ているはずなのに、判断が違う。

もちろん、役割や分析の観点によって意見が異なること自体は問題ありません。

問題は、会社の方針や、判断に使っている情報がAI担当者ごとに違っていることです。

例えば、会社として今月は利益率よりも新規顧客の獲得を優先する方針だったとします。

その方針を知っているAIは、多少広告効率が悪くても出稿を提案するでしょう。

一方、知らないAIは、広告効率の悪化を理由に予算削減を提案するかもしれません。

どちらのAIも、それぞれ与えられた情報の範囲では合理的に判断している可能性があります。

しかし、会社全体としては困ります。

これを防ぐには、会社の経営方針、判断基準、商品情報などを共通の情報源として管理し、各AI担当者が必要な情報を参照できるようにする必要があります。

人間の組織でいう、経営方針の共有や業務マニュアルの統一です。

ただし「共通ルールを作った」だけでは、届いていない

ここは当社がはっきり失敗した部分です。

当社には、全担当が守る共通ルールを書いたファイルがあります。そこに全社方針を書き、各担当の定義ファイルからそれを参照する形にしていました。

ところが、「できません」で報告を終える担当が続いたので調べてみたら、呼び出し方によっては、その共通ルールのファイルを一行も読んでいないことが分かりました。

当社のAI担当者は、名前を呼んで直接やり取りする使い方と、ほかのAIから仕事を振られる使い方の2通りで動きます。後者では、担当者自身の定義ファイルしか読み込まれない作りになっていたのです。

方針は共通ルールにも会社の知識ベースにも書いてありました。書いてあったのに、その担当には最初から届いていなかったわけです。

似た失敗がもう一つあります。別のパソコンへ配った文書の中で、「詳しくはこのファイルを見ること」と自分のパソコンのフォルダを指していました。受け取った側ではそのファイルが開けません。配った側は自分の画面で開けるので、壊れていることに気づけない。これを1日のうちに2回やりました。

教訓は単純です。

共通の情報源を作ることと、それが実際に読まれていることは、別の話です。

ルールを置いたら、そのルールを本当に受け取っているかを確かめるところまでやったほうがいいです。当社では、ファイルを読ませない状態でAI本人に「あなたの指示文に○○は書かれていますか」と聞いて確かめています。

3. 昨日までできていた仕事が、今日はできない

これも厄介な問題です。

昨日まで普通にできていた作業が、突然できなくなる。

例えば、毎朝売上を集計していたAIが、ある日突然、

と聞いてきます。

いやいや、昨日まで自分で取りに行っていたでしょう、と。

原因はいろいろ考えられます。

会話の履歴が失われたのかもしれません。

必要な設定が読み込まれていないのかもしれません。

データの保存場所が変わったのかもしれません。

外部サービスとの接続が切れている可能性もあります。

当社の実例：ルールの配布が、無言で失敗していた

当社でいちばん気味が悪かったのは、これです。

会社のルールは1か所で書き、そこから各AIの手元へ自動で配る仕組みにしています。その仕組みには「配るファイルが大きくなりすぎたら中止する」という安全装置が入っていました。

ここに落とし穴がありました。上限を超えたとき、この仕組みは何も書かずに、前の版をそのまま残すのです。

しかも配布は裏側で自動的に走るので、失敗の表示を誰も読みません。

結果どうなるか。

「配布が止まった」のではなく、「古いルールが正常に配られ続ける」。

もう一つ、同じ型の罠がありました。同じAIでも、どのフォルダで起動したかによって、参照する記憶の置き場が変わることがあります。昨日と同じAIに同じことを聞いているつもりで、実は昨日の記憶が入っていない箱を開けていた、という状態です。

ハーネスが整っていない場合、こうした原因を調べること自体が難しくなります。

一方、仕事の手順、使用するデータ、実行履歴、エラーの記録が残っていれば、何が変わったのか追跡できます。

AIが失敗しない仕組みも大事ですが、失敗したときに原因を特定できる仕組みも同じくらい大事です。

4. AIが勝手に仕事を進めてしまう

AIの自律性が高まるほど、大きな問題になる部分です。

例えば、ECサイトの商品情報の整理を頼んだとします。

こちらは商品名や説明文の改善を想定していたのに、AIが良かれと思って販売価格まで変更してしまった。

あるいは、古いファイルを整理するように依頼したら、必要なデータまで削除してしまった。

AIは仕事を進めようとしているだけかもしれません。

しかし、会社の仕事には、担当者が判断してよい範囲と、許可が必要な範囲があります。

ここを明確にしておかないと、AIの積極性が事故につながります。

例えば、

• 商品説明文の下書き作成は自由
• 商品情報の公開は、定められた検査に合格した場合のみ
• 価格変更は別の承認条件を満たす必要がある
• 大量の商品削除はAI単独では実行できない

といった決まりです。

重要なのは、単に「勝手に削除しないこと」と文章で指示するだけでは不十分だということです。

実際に削除できる権限を制限したり、危険な操作をシステム側で止めたりする必要があります。

当社の実例：「テストのつもり」は、仕組みに伝わらない

これは身内の失敗談です。

異常を知らせる見張りの仕組みを作っている最中、動作確認をしたいので、担当AIがメッセージの送信行を一時的に無効化してから実行しました。

ところが、その一時的な書き換えが当たっていませんでした。

結果、偽の警告が、本番の社内チャットに実際に流れました。

すぐ消しましたが、その間に読んだ人にとっては本物の異常です。消しても「見なかったこと」にはできません。

ここから決めたことは2つです。

• 送信する仕組みを作るときは、送らずに文面を画面へ出すだけの経路を、最初に作る。あとから付けるのでは遅い。
• 削除のように取り返しのつかない操作は、承認制にするのではなく、そもそも代行しない作業として分類する。当社では、モールの商品ページや受注データの削除は「承認をもらえばやってよいもの」ではなく、「AIは実行しないもの」に分けています。

人間の社員でも、入社初日から会社の銀行口座や商品価格を自由に操作できるわけではありません。

AIにも同じ考え方が必要です。

5. 仕事をしたと報告するのに、実際には終わっていない

これはAIエージェントを運用するうえで、特に気をつけたい問題です。

AIに100商品の登録を依頼したとします。

しばらくすると、

と報告してきます。

ところが実際に確認すると、登録できていたのは92商品だけだった。

残り8商品はエラーになっていた。

AIは、プログラムを実行したことと、期待した結果が得られたことを混同する場合があります。

例えば、登録処理を100回実行したから、100商品登録したと判断してしまう。

当社の実例：「受付」を「完了」と読んで、締切を逃した

これは実害が出ました。

あるモールのセール企画に参加するため、申請データをアップロードしました。画面には「処理中」と出ています。担当AIはそれを見て「完了しました」と報告してきました。

実際には、その処理は失敗していました。気づいたときには、早めに申請した店だけが受けられる割引の締切を過ぎていました。

同じ型の失敗を、ほかでも何度かやっています。

• 処理が「完了」と表示されていても、よく見ると「0/2件が設定されました」と書いてある。完了していて、かつ成功ゼロ、という状態が存在します。
• 書類の自動仕分けで「0件処理しました」が、毎日正常として報告されていました。実際には形式の合う書類にしか効かない作りで、肝心のものを1件も拾っていませんでした。
• 逆の向きもあります。書き込んだ直後の応答が変な値を返していたので失敗かと思ったら、保存後に読み直すと正しく入っていた、ということもありました。

そこから決めた原則です。

提出したことと、通ったことは別。返ってきた応答ではなく、保存されたデータを読み直して判定する。

100商品の登録を指示したなら、登録先のシステムから実際の結果を取得し、100商品すべてが登録されているか検査する。

失敗した商品があれば再実行し、それでも失敗するものだけを報告する。

そこまで含めて、一つの仕事として設計する必要があります。

「やりました」という報告と、「実際にできています」という事実は違います。

6. 止まったことに、誰も気づかない

AIに仕事を任せると、必ず見張りの仕組みを作ります。失敗したら知らせてくれ、というものです。

ところが、この見張りが無音で死にます。

当社で実際にあった出荷通知の漏れでは、こうなっていました。

• 夕方のバッチが失敗した日、見張りは当日ちゃんと警告を出していた。ところが翌日以降は何も言わない作りだった。誰も拾わないまま4日間過ぎた。
• 別の日次チェックは、「追跡番号が入っているのに未出荷」だけを異常としていた。番号が入らないままのものは「正常な待ち」として除外していた。今回の事故はまさにその形だったので、5日間・10回とも「異常なし」で通った。

ほかにも、見張り役がAI本体と同じ仕組みの中にいたため、本体が止まると見張りも一緒に止まっていた、ということがありました。自分の生存を自分で報告する作りだと、起動直後に落ちた日は完全に無音になります。

ここから決めたことです。

• 1回鳴らして終わりにしない。直るまで毎日鳴らす。 通知が出たことと、人に拾われたことは別です。
• 「正常な待ち」として除外している条件に、必ず時間の上限を付ける。 何時間たっても待ちのままなら異常、とする。
• 見張りはAIの外に置く。 本体と同じ仕組みの中に置かない。
• 新しく見張りを作ったら、過去に実際に起きた事故のデータで1回流して、ちゃんと鳴ることを確かめる。 鳴るテストを書かないと、沈黙側の穴が残ります。

逆に、鳴りすぎる見張りも同じくらい危険です。毎日誤報が出る見張りは誰も読まなくなるので、結局は無音と同じになります。当社では、通知を新しく作ったら「鳴ってほしくない状況」でも一度流して確かめるようにしました。

7. AIが仕事を途中で止めてしまう

AIに仕事を頼むと、途中まで進めて、

と人間に作業を求めてくることがあります。

もちろん、認証やサービス側の制約で、人間による操作が避けられない場合もあります。

ただし、その前に自動化できる方法を十分に調べているでしょうか。

例えば、管理画面からCSVをダウンロードする業務でも、公式APIというシステム同士がデータをやり取りする仕組みが用意されていれば、画面を操作せずに取得できる場合があります。

サービス側の自動連携や、メールでの定期配信を利用できる場合もあります。

当社では、自動化を考えるときの順番を決めています。

• 公式のAPI（システム同士が直接データをやり取りする仕組み）
• サービス側の自動連携にデータを集め、そこから受け取る
• メール添付やレポートの定期配信を受ける
• ログイン済みの状態を保ち、そもそも再ログインが起きないようにする

この4つを全部当たって、どれも取れないときだけ、人の手を借ります。

当社の実例：「相手の規制」は、実在しなかった

ここで一つ、かなり恥ずかしい話があります。

あるモールの管理画面に自動で入る仕組みが、よく失敗していました。担当AIからの報告はずっと同じで、「相手側の規制に引っかかっているので入れません」。

こちらもそう思い込んで、しばらく放置していました。

あとで調べ直したところ、その規制は実在しませんでした。

原因は全部こちら側の条件でした。すでにログインできているかどうかの判定を取りこぼしていた。人が同じ画面を使っている最中だった。開きっぱなしの画面が溜まっていた。それだけです。

そこから、2つのことを疑うようになりました。

• 「相手のせいでできない」という報告は、まず自分側を疑う。 原因を外に置くと、そこで調査が止まります。
• 「できません」で止まる報告を見たら、AIの能力ではなく、その担当の指示書に「詰まったときの次の行動」が書かれていないことを先に疑う。 当社で「ログインできません」が続いたときも、担当の指示書には「ログインは自分で行う」の一行しかなく、詰まった先に何をするかが書かれていませんでした。

毎日人間が操作しないと進まない仕組みでは、AIに仕事を任せたとは言い切れません。

人間の作業を減らすはずが、いつの間にかAIの作業を補助するために人間が働いている。

これでは本末転倒です。

ただし、完全無人化を目指すからといって、すべての操作を無理やり自動化してよいわけではありません。取り消せない操作や危険性の高い業務については、実行条件や権限を慎重に設計する必要があります。

8. AIに仕事を任せたはずなのに、管理する人が忙しくなる

実は、これが経営者にとって一番大きな問題かもしれません。

AI担当者を何人も導入したとします。

それぞれが仕事をしてくれるので、人間の作業時間は減るはずです。

ところが現実には、

AI担当者Aのミスを修正する。

AI担当者Bから質問が来る。

AI担当者Cの仕事が止まっている。

AI担当者Dの報告を確認する。

AI担当者Eが何をしているのか分からない。

気づけば、AI担当者の管理だけで一日が終わってしまう。

これでは、社員を5人増やしたのと同じような状態です。

当社の実例：承認を減らそうとして、承認を増やしていた

当社は十数名のAI担当者を動かしていて、この問題を正面から踏みました。

最初は、危ない作業だけ私の承認を求める仕組みを作りました。危なさの判定は、計画書に出てくる言葉で見ていました。

これが逆に効きました。

• 丁寧に書いた計画ほど止まる。 「元に戻す方法：該当行を削除すれば戻ります」という親切な説明が、「削除」の語に引っかかって承認待ちになる。「承認をお願いします」と書いた計画が、「承認の仕組みを触る作業」と判定されて止まる。止まっていた14件を調べたら、5件がこの型でした。やると言っている部分ではなく、やらないと言っている部分を危険の証拠として読んでいたわけです。
• もっとひどいのもありました。私が「承認します」と返事をすると、その返事自体が新しい依頼として登録されていた。 行き先の承認待ちが見つからなかったときに「では新しい用件だろう」と解釈する作りだったのです。実測したら、私が呼ばれた16件のうち4件がこの形でした。しかも2本目は同じ作業をもう一度やろうとするので、二重実行の一歩手前でした。直したら、私が呼ばれる回数は16件から5件に、承認待ちは5件から1件に減りました。
• 「承認が多い」と感じていた原因の最大の塊は、実は区分の切り方でした。「お客様の目に触れるもの＝社外への発信」でひとくくりにしていたため、商品ページの説明文を直すといった日常の作業までが、全部私の承認に回っていたのです。売り場の更新を別の区分として切り出したら、承認は一気に減りました。

ここで必要なのが、AIの仕事を管理する仕組みです。

誰が、どの仕事を、どこまで進めているのか。

止まっている仕事はないか。

失敗した作業は自動でやり直せるか。

人間の判断が必要な案件だけを報告できるか。

そしてもう一つ、AIは放っておいても24時間働くわけではありません。 ここは誤解されやすいところです。

チャットで返事を書き終えたAIは、そこで止まります。「明日の朝までにやっておきます」と言っても、翌朝にそのAIを起こす仕組みがなければ、何も起きません。AIが怠けているのではなく、動かす仕組みを用意していないだけです。

逆に、起こす仕組みを作れば、本当に24時間動きます。そうなると今度は、人間が寝ている間にも問題が積み上がる。だから6番の見張りが要る、という話につながります。

AI担当者が増えるほど人間の管理負担も増えるのであれば、それはAI組織ではなく、管理対象を増やしているだけです。

9. AI同士で話し合っているのに、会社が改善しない

複数のAI担当者を導入すると、AI同士に会議や反省会をさせることもできます。

例えば、失敗したAIに別のAIが、

と指摘する。

失敗したAIは、

と回答する。

一見、組織として成長しているように見えます。

しかし、それだけでは何も改善していません。

重要なのは、なぜミスが起きたのかを調べ、その原因を取り除くことです。

商品情報が間違っていたなら、情報の取得方法を修正する。

担当範囲が曖昧だったなら、権限を明確にする。

必要なルールを読み込んでいなかったなら、読み込み方法を見直す。

そして、同じ条件で再び問題が発生しないか検査する。

当社では、「再発防止します」という言葉を対策として数えません。 対策に数えるのは、機械の検査にしたうえで、わざと異常を起こしてみて、ちゃんと鳴ることを確かめたものだけです。

反省会そのものが悪いわけではありません。

ただ、AIが反省したことと、システムが改善されたことは別物です。

この違いを理解しておく必要があります。

（AIの反省については、別の記事「AIの「再発防止します」を信用してはいけない」でも書いています）

10. AIが増えるほど、会社の仕組みが壊れていく

これは、複数のAIエージェントを使う会社で起こりうる、さらに深刻な問題です。

例えば、会社に共通の業務ルールがあったとします。

ところが、AI担当者AもBもCも、自由にそのルールを書き換えられる状態になっている。

Aが自分の仕事のためにルールを修正する。

Bが別の仕事で不都合を感じて、さらに書き換える。

Cが古い情報をもとに、以前の状態へ戻してしまう。

すると、昨日まで動いていたAI担当者Dの仕事が突然動かなくなる。

問題が発生したので、また別のAIが設定を書き換える。

こうして、修正すればするほど全体が不安定になっていきます。

人間の会社でいえば、社員全員が勝手に就業規則や業務マニュアルを書き換えているような状態です。

当社では、業務手順書を書き換えてよいのは、私と、その担当の上司として権限を与えた人だけに限っています。それ以外から改善提案が出ても、いきなり正式なルールにはせず、確認待ちとして別に置きます。

当社の実例：読み替えが、いつのまにか権限になっていた

それでも抜けます。

ある日の私の発言が、別の日の別件への回答として「読み替え」られ、そのまま計画になり、承認を通って実行されていたことがありました。データベースの削除権限を広げる、という内容です。

私はその決定を覚えていません。記録もどこにも残っていませんでした。あとで「誰がいつ広げたのか分からない」と別の担当が報告してきて、ようやく気づき、権限を元に戻しました。

「○○の件への回答として受け取りました」と読み替えられた計画は、承認されても、本人の記憶には残りません。

変更履歴を残し、ほかの業務に影響しないか確認し、問題があれば元に戻せるようにしておく。そして、決定を記録するところまでを実行に含める。

AI担当者を増やす前に、会社全体の仕組みを誰が管理するのか決める必要があります。

11. AIを導入したのに、本当に儲かっているのか分からない

AIが仕事をしてくれるようになると、いろいろな作業を自動化したくなります。

売上集計、広告分析、商品登録、記事作成、在庫管理、顧客対応。

できることはどんどん増えていきます。

ところが、ここで忘れがちなのが費用対効果です。

例えば、毎日10分で終わる作業をAIで自動化したとします。

そのために複雑な仕組みを作り、毎月費用が発生し、エラーのたびに修正が必要になる。

これでは本当に効率化できたのか分かりません。

もちろん、作業時間の短縮以外に、ミスの削減や24時間対応などの価値もあります。

しかし、その効果を測っていなければ、AI導入の成否を判断できません。

測れないと思っていたら、測れた

当社も長いあいだ「だいたいこれくらい使っているはず」で済ませていました。

あるとき、実際に手元の実行履歴から使用量を集計してみました。やってみると、推測と現実はかなり違いました。

いちばん意外だったのは、使用量の内訳です。消費の9割以上が、新しく考えるための分ではなく、すでに渡してある情報の読み直しでした。

つまり、費用を左右しているのは「どのAIモデルを使うか」よりも、どれだけの量を、何本、何回動かしているかのほうだったのです。同時に走らせているセッションの数、無人で回している定期実行の本数。そこが効いていました。

この内訳が見えるまで、私は単価表だけを見て判断しようとしていました。それでは答えを間違えます。

本来は、仕事ごとに、

• AIを動かすための費用
• 人間の作業が何時間減ったか
• エラーや手戻りがどれだけ発生したか
• 売上や利益にどのような効果があったか

を確認できることが望ましいと思います。

AIをたくさん動かしていることと、会社の利益が増えていることは違います。

では、ハーネスには何が必要なのか？

ここまで読んでいただくと、AIの問題だと思っていたものの多くが、仕事の仕組みの問題だということが分かると思います。

ハーネスにはさまざまな構成がありますが、会社でAIエージェントを使うなら、私は次のような要素が重要だと考えています。

これを全部、自分で一から開発する必要があるわけではありません。

既存のサービスやツールに備わっている機能を利用しても構いません。

重要なのは、自社のAIが仕事をするうえで、必要な仕組みが存在し、実際に機能していることです。

ハーネスを作り込まないと、AIエージェントは使えないのか？

ここは誤解してほしくないところです。

最初から大がかりなハーネスを構築する必要はありません。

例えば、AIに商品の紹介文を考えてもらうだけなら、必要な商品情報を渡して指示するだけでも十分です。

特定のExcelファイルを加工してもらうだけでも、それほど複雑な仕組みは必要ないでしょう。

問題は、AIに任せる仕事が増え、継続的に動かし、複数の担当者が利用するようになったときです。

単発の仕事なら、途中で失敗しても人間が気づいて修正できます。

しかし、毎日何十件、何百件という仕事を自動で処理するようになると、そうはいきません。

人間がすべてを確認していたのでは、自動化の意味がなくなります。

だからこそ、AIに任せる仕事の規模と危険性に合わせて、ハーネスを整備していく必要があります。

ここに挙げた仕組みも、当社が最初から持っていたものではありません。全部、事故を起こしてから足したものです。順番としては、実際に困ったところから1つずつで十分だと思います。

最初から大企業のようなシステムは必要ない。しかし、仕事を増やしていくなら、それを支える仕組みも成長させなければならない。

私はそう考えています。

AIの性能が上がれば、ハーネスは必要なくなるのか？

AIの性能は、今後も向上していくでしょう。

長い情報を理解できるようになり、指示の意図をより正確に読み取り、複雑な仕事を自分で進められるようになると思います。

そうなれば、今は細かく設定しているルールや手順の一部は不要になるかもしれません。

しかし、会社の方針や判断権限、実際のデータとの接続、仕事の結果確認などは、AIが賢くなっただけでは解決しません。

会社の今月の経営方針は、AIが勝手に知ることはできません。

どこまで値引きしてよいかも、会社が決めなければ分かりません。

顧客に商品が届いたかどうかも、実際の配送情報を確認しなければ分かりません。

そしてこの記事で挙げた失敗を見直すと、AIが賢ければ防げたものは、ほとんどありません。 設定ファイルの書き間違いで見張りが動いていなかった。ルールの配布が無言で失敗していた。「処理中」の画面を完了と読んだ。どれもAIの知能の問題ではなく、仕組みの形の問題です。

AIがどれほど優秀になっても、会社固有の情報と仕組みは必要です。

むしろ、AIができる仕事が増えるほど、そのAIに何を任せ、どこまで権限を与えるのかという問題は重要になると思います。

まとめ：AIを育てるとは、AIに何度も注意することではない

私はAIエージェントを使い始めた頃、AIに仕事を教え、失敗したら注意して、次第に仕事ができるようになっていくものだと考えていました。

もちろん、指示の出し方や情報の与え方によって、AIの仕事の質は変わります。

しかし、使い続けるうちに、それだけでは限界があると感じるようになりました。

AIが失敗したら、なぜ失敗したのかを調べる。

必要な情報がなかったのか。

ルールが曖昧だったのか。

仕事の手順が間違っていたのか。

そもそも、その操作をAIに許可すべきではなかったのか。

原因が分かったら、それを仕組みとして改善する。

そして、同じ失敗が起きないか検証する。

これを繰り返すことが、会社でAIエージェントを育てるということなのだと思います。

人間の社員なら、経験を積むことで仕事を覚え、周囲の状況を理解し、会社のやり方にも慣れていきます。

しかしAIの場合、そうした経験が自動的に会社全体の知識やルールとして蓄積されるとは限りません。

だから、学んだことを残し、次の仕事に反映させる仕組みが必要になります。

AIエージェントの性能が高いことと、そのAIが会社で仕事をできることは、別の話です。

高性能なAIを契約しただけでは、優秀な社員を採用したことにはなりません。

そのAIが仕事をできる環境を整えて、初めて会社の戦力になります。

AIのモデル選びやプロンプトの工夫も大事ですが、ある程度AIを使い込んだ会社ほど、次に見直すべきはハーネスなのではないでしょうか。

そして最終的に目指すのは、AIが仕事をして、人間がそれを一つずつ確認する会社ではありません。

AIが仕事をし、結果を検証し、失敗を修正し、必要なときだけ人間に判断を求める。

そんな会社の仕組みを作ることだと思っています。

「AIがミスばかりする会社と、安定して動く会社」を読む コンテンツ一覧へ