Nectoが3つのAIエージェントを設計して学んだ3原則

私たちNectoは、社内の業務を回すために3つのAIエージェントを設計してきました。営業を担う「ケン」、広報を担う「ミナ」、メディア記事を担う「ハナコ」。それぞれを順番に作っていく中で、最初は気づけなかった設計の原則がいくつか見えてきました。本記事では、これからAIを業務に組み込もうとしている不動産会社の方に向けて、設計段階で押さえておきたい3つの原則を、私たちの失敗も含めて共有します。

なぜ「1つの万能エージェント」ではなく3つに分けたのか

最初、私たちは「営業も広報も記事もできる1つの万能エージェントを作ればいい」と考えていました。社内に1つだけシステムがあれば管理が楽だろう、という素朴な発想です。実際に1〜2週間ほど試作を進めて、すぐに行き詰まりました。理由は3つあります。

1つ目は、業務ごとに必要な「らしさ」が違うこと。営業メールは丁寧で要点が短くまとまっている必要があり、SNS投稿は等身大で会話を生む文体、メディア記事は丁寧で噛み砕いた解説調、と求められるトーンが全く違います。1つのエージェントにすべての文体を覚えさせると、どの業務でも中途半端な出力になりました。

2つ目は、業務ごとに必要な情報源が違うこと。営業エージェントは見込み客のリスト、広報エージェントは業界トレンド、メディアエージェントは長文の参考資料、と扱うデータの形が違います。万能型にしようとすると、入力の前処理が複雑になりすぎて手が回らなくなりました。

3つ目は、エラー時の責任範囲が曖昧になること。1つの巨大エージェントが営業メール送信に失敗した時、「広報の部分は正常に動いているか」「メディア記事は影響を受けたか」といった切り分けに無駄な時間を取られました。結局、業務単位でエージェントを分けることで、トラブル対応が劇的に楽になりました。

原則1：各エージェントは「単機能」に絞る

ここから3つの設計原則を順番に説明します。1つ目は「単機能化の原則」です。1つのエージェントには1つの業務だけを担当させ、その業務の中でも責務をさらに細かく分解する、というアプローチです。

たとえば広報エージェントのミナは、Threads投稿を作るためだけのエージェントです。さらにミナの内部は「ネタを集めるチーム」「下書きを書くチーム」「校正するチーム」の3チームに分かれており、それぞれは独立したPythonの関数として実装されています。1チーム1関数、1関数1責務、という分け方を徹底することで、どこかが壊れても他に波及しません。

この原則は、ソフトウェア設計で昔から言われている「単一責任の原則」と同じ考え方です。ただAIエージェントの場合、責務が曖昧だと出力品質が一気に落ちるため、人間のコード以上に厳格に守る必要があると感じています。「これも、あれもやらせよう」と機能を足したくなった瞬間に立ち止まり、新しいエージェントを別に作るほうが結果的に近道です。

原則2：ランニングコストゼロを優先設計する

2つ目は「コスト構造の原則」です。私たちは設計の早い段階で「このエージェントは月いくらかかるか」を必ず試算し、できるだけランニングコスト（毎月発生する固定費）がゼロになる構成を選ぶようにしています。

具体例を挙げます。名刺管理エージェントを作る時、有料のAI画像理解API（オーシーアール、画像から文字を読み取る技術をAIで行うサービス）を使えば精度は高くなりますが、1枚処理するごとに数円から十数円のコストがかかります。月100枚処理するだけで毎月の固定費が増えていきます。私たちは代わりに、EasyOCRというオープンソース（無料で使えるソフト）と、正規表現（文字パターンを記号で表すルール）を組み合わせた構成を選びました。精度は95%程度ですが、月額は0円です。

この選択は単にケチっているわけではなく、戦略的な意味があります。中小の不動産会社にAI業務効率化を提案するとき、「月3万円かかります」と「月0円です」では、導入のハードルが10倍違います。コスト構造をゼロに寄せておくことで、自社で運用するだけでなく、お客様にそのまま技術を移植できる、という二重のメリットが生まれます。

ただし、すべてをローカル処理にするのは現実的ではありません。長文の記事生成や、複雑な文脈理解が必要な処理ではClaudeなどのAIを使うしかない場面もあります。その場合は、使用量に明確な上限を設けて、月額予算を超えそうになったら自動で止まる仕組みをセットで設計します。

原則3：人間のレビューを「省略可能」にしない

3つ目は「人間レビューの原則」です。AIエージェントを設計するとき、「最終的には人間が確認しなくても回るようにしたい」という誘惑が常にあります。私たちもその誘惑に何度も負けかけましたが、結論として「人間のレビューは絶対に省略できないステップ」として設計に組み込むようにしています。

理由は2つあります。1つ目はGoogleなど主要な検索エンジンが、人間の関与のない自動生成コンテンツに対して評価を下げる傾向があるためです。SEO（検索エンジン経由の集客）を狙うメディアでは、人間のレビューを省くと検索順位が落ち、自動化のメリットが帳消しになります。2つ目はブランド毀損のリスクです。AIが誤った情報や不適切な表現を出力したまま公開してしまうと、それが会社の信用に直結します。レビューを省略して得られる時短は数分ですが、失う信用は取り戻すのに数年かかります。

ハナコの設計でも、最後の公開判断は必ず人間が行う前提でフローを組んでいます。記事は自動でレビュー待ちフォルダに入り、編集長がチェックして承認したものだけが公開されます。AIに「最終決定権」は渡さない、これが3つ目の原則です。

失敗：最初は1つの万能エージェントで作ろうとした

恥ずかしい話ですが、最初の試作で1つの万能エージェントを作ろうとして、2週間まるごと無駄にしました。当時の私たちは「分けるより1つにまとめた方が美しい設計だ」と思い込んでいたのです。

行き詰まった原因は、先ほど挙げた「文体の混在」「データ形式の違い」「責任範囲の曖昧さ」の3つでした。途中で気づいて方針転換し、業務単位で分割する設計に切り替えてから、開発スピードが3倍ほどに上がりました。早い段階で分割できなかったのは反省点ですが、この失敗があったからこそ「単機能化の原則」を強く守るようになったとも言えます。

まとめ：エージェント設計は「分けて」「安く」「人と一緒に」

3つの原則を改めてまとめます。1つ目は単機能化、1エージェント1業務に絞ること。2つ目はランニングコストゼロを優先、ローカル処理を最大限活用すること。3つ目は人間のレビューを省略せず、最終判断は人が握ること。この3つを守るだけで、AIエージェントの設計は驚くほどシンプルになり、運用後の事故も減ります。

Nectoでは、こうした設計原則をベースに、不動産会社の業務に合わせたAIエージェントの設計・実装を支援しています。「うちの会社にもこういうのを作りたい」「どこから始めればいいか分からない」というご相談はいつでも歓迎です。