
Service 03
OUR APPROACH
AIエージェント(人の指示を受けて、判断しながら一連の作業を自動で進めるAI)の開発でARCHECOが何を先に設計するか、という考え方は、自社で運営しているサービスでの経験にいちばんはっきり表れています。その経験は、ブログ記事「チャットボットの作り方」に詳しく書きました。このページでは、記事を読まなくても分かるように、要点だけをまとめています。さらに詳しく知りたい方は、ページ末尾のリンクから記事をご覧いただけます。
AIエージェントが実際の運用で想定外の動きをするかどうかは、AIの賢さではなく、止まるべき場面で確実に止まる仕組みがあるかどうかで決まります。
多くの開発では、AIエージェントの賢さを、プロンプト(AIに与える指示文)を書き足すことでつくり込みます。「こういう場合はこうする」という指示を増やしていけば、正しく動くはずだと考えるからです。ところが実際に運用すると、想定していなかった入力が必ず届きます。そのとき、プロンプトはあくまで指示であって、AIの動きを止める仕組みではありません。
ここで、ARCHECOが自社で運営しているサービスの話を紹介します。AIエージェントがどのように想定外の動きをするのかを、最初から最後まで自分たちで見られた例だからです。このサービスでは、ホテルに泊まっている旅行者がチャットから申し込む荷物の配送を、受付から決済、業務システムへの登録までAIエージェントに任せていました。あるとき、受付を閉じていた深夜の時間帯に旅行者が「荷物を預けたい」と打ち込み、AIエージェントがそのまま受け付けて決済まで進めてしまいました。その結果、配送は始まっていないのに、旅行者のクレジットカードの利用可能額だけが減ったままになりました。もう1つの不具合に気づいたのは、その月に外部のAIサービスから届いた利用料の請求書が、想定より高かったときでした。旅行者が「近くにおいしい店はあるか」「明日の天気は」といった荷物と関係のない雑談を打ち込むたびに、AIエージェントが外部のAIサービスを使って丁寧に答え、その分の料金が積み上がっていたのです。この2つの不具合の原因は、AIの性能ではありませんでした。利用者の入力とAIの間に、「これは受け付けない」「これは人が対応する」「これは料金のかからない方法で処理する」と振り分ける仕組みが無かったことでした。
旅行者の申込みを、社内の申請処理や顧客対応に置き換えても構造は同じです。止まるべき場面を仕組みとして持たないAIエージェントは、賢くするほど、想定外の入力に対して想定外の動きをします。つまり、AIエージェント開発で先に設計すべきなのは、賢さではなく「止まるべき場面と、人に引き継ぐ条件」です。
だから、ARCHECOは
そのため、ARCHECOのAIエージェント開発では、LLM(大規模言語モデル。文章を理解し、生成するAI)の手前に、届いた入力を「受け付ける」「受け付けない」「人が対応する」に振り分ける仕組み(分類器)を先に1つ置くことから始めます。AIに任せる範囲と止まる場面を先に設計し、「とりあえず動く」ではなく「止まるべき場面で確実に止まる」AIエージェントを実際の運用に出します。これは、自社サービスを運用しながら固めてきた設計です。
AIエージェントの開発でつまずくのは、技術的に動かないからではありません。単一のLLM呼び出しに全部を任せると、複雑な業務は途中で止まります。止まった場所が分からないまま「なんとなく動いた」状態で本番に出すと、本来は任せてはいけない処理まで通してしまう事故につながります。必要なのは、複数のAIモデル・外部ツール・データベースを連携させ、どこで止めるかまで決めて動くエージェント設計です。
ARCHECOは、AIエージェントに何かを任せる前に「タスク分解・ツール選択・実行計画・停止条件」の4つを先に決めます。なかでも要になるのが停止条件です。間違えたときに取り返しがつく処理(下書きの生成、候補の絞り込み、定型レポートの作成など)はエージェントに任せ、取り返しがつかない処理(決済・在庫の引き当て・受注の確定など)はシステム側の保証に残す。この境界を設計の最初に引くことで、LLM単体では届かない精度の先を仕組みで補います。LangChain・LangGraph・CrewAI等のフレームワークは、この設計を実装する手段として使い分けます。
複雑な業務を最後まで遂行し、かつ止まるべき場所では確実に止まるAIエージェントを提供します。目安として、要件が固まった業務であれば、通常の見積りで15〜25人月相当かかる実装を3日で立ち上げ、本番で異常が起きた場合も検知から恒久対応まで最短1時間で戻す運用体制まで含めて構築します。「作れるか」ではなく「本番で運用しきれるか」を基準に設計します。

01
STEP 01
自動化対象の業務を分析し、間違えたときに取り返しがつく処理とつかない処理を先に切り分けます。エージェントに任せる範囲・システム側で保証する範囲・マルチエージェント構成の要否をここで確定し、あとから境界がぶれないようにします。
Method
業務タスク分解分析
エージェントアーキテクチャ設計
ツール連携要件定義
Output
エージェント要件定義書
アーキテクチャ設計図
タスク実行ロジック・実行計画・再試行の判断を担うコアを先に作り、社内API・検索/RAG・外部SaaSといったツールは1つずつ接続します。まとめて繋ぐと、失敗した時にどこが原因か分からなくなるため、つなぐ順番自体を設計対象にします。会話の文脈・処理の途中状態・実行履歴を保持するメモリ管理も、この段階で組み込みます。
Method
エージェントコア開発
ツールプラグイン実装
メモリ・状態管理設計
Output
AIエージェントシステム
ツール連携モジュール
タスク完遂率・判断精度・処理速度・エッジケースでのフォールバック成功率の4つの指標を、実際の業務データで測定します。平均値だけでは見えないため、完遂できなかった1件がどこで止まったかを毎回開いて確認し、フォールバック処理をチューニングします。
Method
シナリオベーステスト
精度・性能評価
フォールバック設計
Output
テスト結果レポート
チューニング済みエージェント
本番へは段階的にデプロイし、稼働と処理量を常時監視します。API呼び出しの失敗のように「エラーが出る異常」は監視ツールで自動検知できますが、「受け付けてはいけない依頼を通してしまった」「作られるはずの記録が無い」といった、エラーが出ない異常は数えて突き合わせない限り気づけません。この突き合わせの仕組みまでを運用設計に含め、異常検知から恒久対応までを最短1時間で回せる体制を構築します。
Method
デプロイメント自動化
監視ダッシュボード構築
アラート設計
Output
デプロイ済みエージェント
運用監視システム
障害対応手順書
PROOF
AIエージェントは「作れるか」ではなく「本番で運用しきれるか」で差が付きます。ここに並べたのは一般論ではなく、実際に本番環境で出した数字です。
CASE STUDIES
CASE TYPES
自社で本番運用しているAIプロダクトと、受託で設計・開発したエージェントの類型を並べています。固有名は公開済みの実績だけで、他は守秘の範囲で類型と支援範囲のみです。
ABOUT AI AGENT DEVELOPMENT
AIエージェント開発を検討している方に向けて、仕組みとチャットボット・RPAとの違い、開発方式の選択肢、設計で先に決めること、費用が何で決まるか、よくある失敗、外注先の選び方、そして意外と語られない本番運用の壁までを整理しました。
AIエージェントは、目標を与えると自分で手順を考えて道具を使い、タスクを進めるAIです。チャットで答えるだけのAIとの違いは「自分で動くか」にあります。AIエージェント開発とは、このAIを業務に組み込める形で設計・構築・運用することで、要点はモデル選びより「何を任せ、どこで止めるか」の設計にあります。
中核の言語モデル(考える)、外部ツールの呼び出し(動く)、文脈の記憶(覚える)の3点で構成されます。この構成が意味するのは、賢さはモデルだけでは決まらないということです。どの道具を、どの権限で持たせるかの設計が、実用性の大半を決めます。
従来のチャットボットは決めた筋書きに沿って答え、生成AIチャットは聞かれたことに答えます。エージェントは目標から逆算して、複数の手順を自分で実行します。逆に言えば、1問1答で済む業務にエージェントは過剰です。この見極めを間違えると、開発費だけが膨らみます。RPAとの違いも同じ軸で、手順が完全に決まっている定型作業はRPAのほうが安く確実に動き、文章の理解や状況判断が挟まる業務がエージェントの領分です。
海外ではエージェンティックAI(Agentic AI)という呼び方が主流になりつつあります。使い分けは、AIエージェントが「個々の実行主体」を指すのに対し、Agentic AIは「目標を与えると自律的に計画・実行するAIの設計思想」を指す、という程度です。呼び名は違っても、開発で問われることは同じ——どこまで任せ、どこで人が判定するか、です。
1つのエージェントに複数の道具を持たせるシングル構成と、役割ごとに分けた複数のエージェントを連携させるマルチ構成があります。マルチ構成は複雑な業務を分割できる代わりに、設計・評価・障害の切り分けの難度が上がります。ARCHECOはまずシングル構成で必要な道具を使える状態を作り、役割分担が複雑になった時点でマルチ化する順序を取ります。要件定義の段階でマルチエージェントの要否を決めるのは、あとから構成を変えると評価と監視を作り直すことになるからです。
実務で動いている例は、社内問い合わせの一次対応、定型レポートの収集と作成、システム監視と一次対応、営業準備の情報収集あたりに集中しています。共通点は「手順は決まっているが分岐が多く、人がやると面倒」な仕事です。創造的な判断の代行は、現時点では実用の中心ではありません。
作り方は3段階あり、どこまで自作するかで費用と自由度が変わります。加えて、既製のプラットフォームを設定して使うのか、自社業務に合わせて受託で作り込むのか、社内で内製するのかという依頼先の軸があります。どちらの軸も、検証が済む前に上位の方式を選ぶ理由はほぼありません。
DifyやCopilot系のツールで、画面操作だけでエージェントを組めます。速くて安い代わりに、ツールの想定した形しか作れません。最初の検証はここから始めるのが定石で、いきなりフルコードで作る理由は、検証が済むまでは基本的にありません。
n8nなどの視覚的なワークフローツールで、処理の流れを自分で設計します。既存システムとの接続が要る業務ではこの層が現実解になることが多く、ノーコードで詰まった点をここで解消できるかを先に確かめると、無駄なフルコード開発を避けられます。
LangChainなどのフレームワークでゼロから開発します。自由度が最大の代わりに、精度評価・監視・保守まで全部自前になります。選ぶ基準は「既製ツールでは業務の要件が満たせないと検証で確認できたか」。技術的な興味で選ぶ層ではありません。
依頼先の軸で見ると、既製プラットフォームを設定して使う型、自社業務に合わせて開発会社が作り込む受託型、AI・システム開発の人材を社内に置く内製の3つがあります。プラットフォーム型は短期・低コストで始められる代わりに独自業務への対応に限界があり、内製は改善が速い代わりに運用・評価・セキュリティの体制まで自前になります。基幹システムや社内データとの接続が要る段階で、受託型が現実解になることが多い構図です。ARCHECOは受託型ですが、設計だけを持ち帰って内製する使い方も、既製ツールで足りる部分はそのまま使う構成も選べます。
開発の成否は、コードを書き始める前の設計でほぼ決まります。ARCHECOがAIエージェント設計の最初に決めるのは、自動化する範囲、人が判断するポイント、失敗したときの動き、精度の測り方の4つです。この4つが決まっていれば、工程は要件定義からPoC・本開発・本番運用まで素直に流れます。
「何でもできるエージェント」を目指した開発は、ほぼ確実に失敗します。範囲が広いほど精度は下がり、テストは不可能になり、失敗の原因が特定できなくなるからです。1つの業務の、分岐の少ない部分から始めて、動いたら範囲を広げる。地味ですが、本番で動いているエージェントは全部この順序で作られています。
全自動を目指すより、「ここだけは人が承認する」ポイントを設計に残すほうが、結果的に早く本番に載ります。とくに社外への送信・金銭・データの削除に関わる操作は、人の承認を挟む設計が現在の実務水準です。全自動への移行は、運用実績が信頼を積んでからで遅くありません。
エージェントは確率的に動くので、必ず失敗します。問うべきは失敗するかではなく、失敗したときに何が起きるかです。失敗を検知する仕組み、失敗時に安全側へ倒す動作、人へ引き継ぐ経路。この3つが設計に無いエージェントは、デモでは動いても本番に出せません。
「なんか良い感じに動く」は評価ではありません。実際の業務ケースを集めたテストセットを作り、変更のたびに同じセットで測る。この地味な仕組みが無いと、改善のつもりの変更で精度が下がっても気づけません。評価セットの構築は開発の付属品ではなく、開発そのものの一部です。
一般的な工程は、業務課題の整理と要件定義、小さく検証するPoC、本番システムとしての開発、テスト、本番導入と運用改善の順です。期間は要件定義が数週間、PoCがノーコード系なら数週間からで、本開発は接続するシステムの数とテスト工数で数か月単位に伸びる、というのが各社の目安の共通点です。ARCHECOは要件が固まっていればAI自律開発ツールを併用して最初に動くものまで数日から数週間で出しますが、本番投入に必要な異常系の設計と検証は省きません。期間を縮める余地があるのは実装で、境界の設計と評価にかける時間は縮めない、という配分です。
「AIエージェント開発の費用はいくらか」は検索でもよく聞かれる質問で、各社が相場の早見表を載せています。ただ同じ「AIエージェント開発」でも既製プラットフォームの設定で済むのかゼロから作るのかで金額の桁が変わるため、ここでは相場の数字ではなく、金額を動かす変数と、抑え方で答えます。
接続する社内システムの数、扱うデータの機密度(権限設計の複雑さ)、求める精度の水準、そして全自動か人の承認を挟むか。この4つでほぼ決まります。とくにシステム接続数が効きます。エージェント本体より、接続と権限まわりの開発が費用の過半を占める案件は珍しくありません。
初期開発費のほかに、モデルAPIの従量課金、精度監視と改修の工数が毎月かかります。利用が増えるほどAPI費用も増えるため、1回あたりの処理コストを設計時に見積もっておかないと、成功するほど赤字になる構造ができあがります。
各社が挙げる抑え方は共通していて、対象業務を1つに絞る、PoCから本開発への段階契約にする、既製ツールで足りる部分はそのまま使い自社固有の部分だけ作る、の3つです。見積もりを比べる前に、自動化したい業務と現在の工数、任せたい範囲(回答までか、実行までか)、接続が要るシステムの一覧、参照させるデータの整備状況、セキュリティ上の制約を書いて渡すと、各社の見積もりが同じ前提で並びます。ARCHECOはこの整理を無料のAIエージェント診断で一緒に行い、任せてよい範囲とシステムで守る範囲を切り分けたうえで概算をお出しします。
各社が挙げる失敗は、技術的に動かないことより、プロジェクトの進め方と判断の問題に集中しています。ここでは共通して挙がる4つを、ARCHECOならどう防ぐかとあわせて並べます。
複数部署・複数システムを横断するエージェントから始めると、要件も評価方法も複雑になり、失敗したときに原因が特定できません。1つの業務で効果を確認してから横展開するのが現実解です。ARCHECOでは範囲の選定を設計の最初の決定に置き、動いたら広げる順序を崩しません。
「AIが動いた」はPoCの成功ではありません。業務時間がどれだけ減るか、精度がどの水準か、人の修正が何回要るかを、作る前に判断基準として決めておかないと、動くものができた後で議論が振り出しに戻ります。ARCHECOはタスク完遂率・判断精度・処理速度・フォールバック成功率の4指標を実業務データで測る形にして、合格線を先に合意します。
ハルシネーション対策が薄いまま本番に出すと、間違った内容がそのまま実行されます。精度を上げる努力と同時に、受け付けてはいけない処理を通さない停止条件をシステム側に持つのが対策です。ARCHECOは取り返しがつかない処理(決済・在庫・受注など)をエージェントに任せず、システム側の保証に残す線引きを設計の核にしています。
モデルAPI、クラウド、監視、改修の費用は開発費とは別に毎月かかります。ここを稟議に入れずに通すと、翌年度に予算が足りなくなります。ARCHECOは1回あたりの処理コストと運用工数を設計時に見積もり、年間の総額で判断できる形にします。
デモまでは誰でも作れる時代になりました。差が付くのは本番で運用し続ける部分で、検索上位でここを正面から書いているページはごく少数です。
業務の内容・接続先のデータ・モデルのバージョンは全部変わり続けます。作った時点の精度は保存されません。定期的に評価セットで測り直し、劣化したら原因を切り分ける運用が要ります。この運用の工数を初期見積もりに入れていない案件が、リリース後に止まります。
エージェントに与えた権限は、エージェントが誤って使う可能性のある権限です。目標の解釈を誤ったエージェントが、与えられた道具を正しく使って誤った結果を出す、という事故は実際に起きます。権限は業務に必要な最小限に絞り、危険な操作は人の承認を挟む。設計時の1行が、運用時の事故を防ぎます。
本番のエージェントには「なぜその行動をしたか」を後から追える記録が要ります。うまく動かなかったときに原因を特定できない状態は、改善もできない状態です。行動ログと判断過程の記録は、あとから足すのが難しいので、最初の設計に含めてください。
開発会社のタイプ、実績の見方、契約前に聞くべきことを絞って書きます。
各社の整理はおおむね同じで、要件定義と戦略設計が強く実装は外部に出すこともあるコンサル型、大規模システムと既存基幹との接続が得意なSIer型、LLM・エージェント技術に強くスピードが速いAIスタートアップ型、要件定義から運用までを同じチームで担う総合型の4つです。基幹連携が要るならSIer型、まず何を作るかから相談したいならコンサル型か総合型、という向き不向きがあります。ARCHECOは設計・開発・本番運用を同じチームで担う総合型に近く、契約は受託だけでなくプロフィットシェアやJVまで事業フェーズに応じて選べる点が、この分類からはみ出す部分です。
デモやPoCの実績と、本番で運用が続いている実績は別物です。実績を見るときは「それは今も動いていますか」「運用開始からどのくらいですか」と聞いてください。答えに具体が無い場合、その会社の実績はデモまでの可能性があります。
精度の評価方法をどう作るか、失敗時の設計をどうするか、運用に移った後の改修体制と費用はどうなるか。この3つへの答えの具体性で、本番まで持っていける会社かが分かります。モデルやツールの名前しか出てこない提案は、デモ止まりの危険信号です。
NEWS & BLOG
SOLUTIONS
このサービスで使う開発手法・契約モデル・技術方式です。


FAQ
ご相談の前によくいただく質問です。解決しない点はお気軽にお問い合わせください。
01
目標を与えると自分で手順を考え、外部ツールやデータを使ってタスクを最後まで進めるAIを、業務に組み込める形で設計・構築・運用することです。中身は「モデルを選ぶこと」より「何を任せ、どこで止めるかを決めること」に近く、チャットボットの延長ではなく、AIを組み込んだ業務システムの開発として考えたほうが要件を整理しやすくなります。ARCHECOは、任せる範囲・システムが保証する範囲・停止条件を設計の最初に決め、そこから作ります。
02
自動化する業務の範囲と分岐の多さ、接続する社内システム・SaaSの数、エージェントに与える権限(読むだけか、実行までか)、求める精度と業務の重要度、社内データの整備状況、そして本番後の評価・改善の体制。この6つでほぼ決まります。開発費のほかにモデルAPIの従量課金と監視・改修の工数が毎月かかるため、初期費だけでなく年間の総額で見るのが実務では安全です。ARCHECOは無料のAIエージェント診断で範囲と境界を切り分けてから概算をお出しします。
03
ルールが完全に決まっている定型作業はRPAや通常のシステムのほうが安く確実で、1問1答で済む問い合わせ対応はチャットボットで足ります。文章の理解、状況に応じた判断、複数システムからの情報取得と実行が絡む業務が、AIエージェントの出番です。全部をエージェント化する必要はなく、ARCHECOはまず業務の中で「判断が要る工程」だけを抽出し、そこにエージェントを置いて周囲は既存の仕組みで固めます。
04
チャットボットは会話への応答が仕事で、RPAは決まった手順の繰り返しが仕事です。AIエージェントはこの中間にあり、タスクの分解・ツールの実行・結果の検証までを状況に応じて自律的に遂行します。実務で効くのは、会話やツール呼び出しの裏に「任せてよい処理」と「システムが保証すべき処理」の境界を引くことです。この線引きが、本番で事故を起こさないための本体になります。
05
対象業務の複雑さと、エージェントにどこまで任せるかによって変わるため、定額では提示していません。まずは無料のAIエージェント診断で、任せてよい範囲とシステムで守るべき範囲を切り分けたうえで、概算をお出しします。診断の段階で、動くもので判断できる状態にしてお返しします。
06
対象業務の複雑さによりますが、要件が固まっていればAI自律開発ツールを併用し、最初に動くバージョンまでは数日から数週間が目安です。ただし本番投入には異常系の設計と検証が欠かせないため、そこを省いた最短納期はお約束しません。
07
なりません。実案件のチャットボット分類では99.9%まで到達しましたが、それでも100%が必要な処理(決済・在庫・受注など)では予期しない動きをする可能性が残ります。だから精度を上げることと同時に、受け付けてはいけない処理を通さない停止条件と、記録の突き合わせをシステム側に設計します。
Plans
受託開発(1年以内のカスタム開発)、代理出産型プロフィットシェア(ARCHECOが事業運営を主導、無償保証・サービス譲渡確約付き、2〜3年計画)、ジョイントベンチャー(双方が資本出資し事業体を共同設立、2〜3年計画)、スウェットエクイティ(労働力を株式として投下)。事業フェーズとリスク許容度に合わせて、最適な契約形態を設計します。どの契約を選んでも、事業を当てることへのこだわりは変わりません。
Plan 01
ARCHECOのソリューションライブラリと自律型AI開発エージェントを活用し、1年以内でカスタムシステムを構築・納品します。AI戦略策定からAgentic RAG構築、業務特化型プライベートSaaS開発、UX/UIデザインまで、事業に必要な全工程を一気通貫で実行します。

Plan 02
ARCHECOが事業の企画・開発・運営を主導し、2〜3年計画で事業を立ち上げます。無償保証、サービス譲渡確約、採用代行を含むリスク軽減策をセットで提示。事業が黒字化して初めてARCHECOの収益が発生するプロフィットシェア構造により、全員が事業の成功だけに集中します。

Plan 03
クライアント様とARCHECOが資本を出し合い、新たな事業体を共同設立します。双方からの人材出向・採用により、独立した組織として事業を推進。既存事業のルールや予算制度に縛られない「出島」として機能し、スタートアップと同等のスピードと柔軟性で意思決定を行います。

いまの業務のどこがエージェント化に向くか、任せてよい処理と任せてはいけない処理の切り分けを無料で診断します。分厚い提案書は作りません。動くもので判断できる状態にしてお返しします。
※弊社のリソース状況によってはお受け出来ないことがございます。