公開日 ・ 約18分で読めます
自社業務のAIエージェントの作り方。非エンジニアが最初に作る1体
自社業務のAIエージェントの作り方とは、ツールの操作手順ではなく、作らない判断から毎日回す運用までを決める「順番」のことです。非エンジニアの経営者が最初の1体を作るなら、作る前に4つの質問に答え、最も単純な器を選び、合格基準を先に書き、機械と人間のゲートを置き、止まった記録で育てる。この5つの順番を守れば、最初の1体は動き続けます。
僕はAIVESTという会社を経営しながら、自分でも手を動かして自社業務のAIエージェントを作り、毎朝動かしています。検索で出てくる作り方は、ノーコードツールの比較、操作の5ステップ、開発会社のガイドまでは揃っています。この記事はそこに無い「作る前」と「作った後」の順番を、自社で毎回通している設計手順の現物と、このブログ自身がその順番で作られて毎朝動いている実物で埋めます。
自社業務のAIエージェントの作り方とは。最初の1体は「順番」で決まる
作り方とは、5つの順番のこと
AIエージェントの定義、チャットAIとの違い、業務のどこに置けるかの判断基準は、別の記事にまとめてあります。この記事は「置く業務の候補は決まった。さて、どう作るか」の段階から始めます。
関連記事AIエージェントとは。チャットAIとの違いと業務に置ける範囲AIエージェントとは、目標を渡すと道具を使って複数の工程を自分で進めるAIのことです。チャットAI・生成AI・RPAとの違いを比較表で整理し、自社で毎日動かしている実例から、業務のどこに置けるかの判断基準まで経営者向けに解説します。僕が自社でAIエージェントを1体作るとき、毎回同じ順番を通します。
作らない判断。作る前に4つの質問に答え、1つでも答えられなければ作らない
器の選定。最も単純で足りるものを選ぶ
合格基準を先に書く。普通・例外・過去の失敗の3件を、機械が判定できる形で
機械ゲートと人間ゲートを置く。機械が先に止め、取り返しのつかない操作の直前だけ人が押す
毎日回す。止まった記録は消さず、次の合格基準に昇格させる
ツールを選ぶのは2番目で、しかも「最も単純なもの」を選ぶのが答えです。 上位の解説がツール比較から始まるのとは、順番が逆になります。
なぜ順番が先で、ツールが後なのか
AIエージェントは、目標を渡すと道具を使って複数の工程を自分で進めるAIです。つまり、人が見ていないところで結果が出ます。
見ていないところで出た結果を、誰が、何を基準に合格と判定するのか。 ここを決めずにツールから入ると、動いた瞬間は嬉しいのに、翌週には誰も結果を見なくなります。順番は、この問題を作る前に潰すためのものです。
なぜ非エンジニアの最初の1体は動かなくなるのか
最初の1体でよく見るのは「作れなかった」ではなく「作ったのに、動かなくなった」です。原因は3つの欠落に集約されます。
欠落1: ツール比較から入る
「どのツールで作るか」から始めると、選んだツールでできることが、そのまま業務の設計になります。業務に必要な判定や停止の条件は、ツールの機能一覧には載っていません。ツールにできることは全部やるが、業務に必要なことは半分しかやらない1体ができます。
2026年9月にXで広く読まれた投稿に、非エンジニアがAIで開発を始めたあとに抱く感想は「AIがあっても依然として難しい」であり、職業不要論はデモ的にツールを使っているだけ、という趣旨のものがありました（出典は末尾）。デモが動くことと、業務で動き続けることは別物です。
欠落2: 合格基準が無い
「いい感じの議事録を作って」の「いい感じ」は、機械には判定できません。合格基準が無いと、結果の良し悪しを毎回人が読んで決めることになり、それは自動化ではなく「毎日届く下書きの添削」です。そのうち読まなくなり、読まれない結果が溜まっていきます。
欠落3: 人が握る地点が無い
逆に、全部をAIに任せ切ると、取り返しのつかない操作（送信・公開・決済・削除）まで自動で走ります。怖くなって全部止めるか、事故が起きて止めるか。どちらにしても止まります。どこで人が握るかを最初に決めておくと、それ以外は安心して任せられます。
順番①: 作らない判断。作る前に答える4つの質問
僕の自社の規約には、新しい自動化やAIエージェントを作る前に必ず答える4つの質問があります。2026年7月に条文にしたもので、以来、自社の自動化はすべてこれを通してから作っています。候補の業務を洗い出す作業はAI導入の最初の2週間に書いたので、ここでは候補が1つある状態から始めます。
その作業は週1回以上、繰り返すか
結果の合否を、機械が判定できるか（検査項目・しきい値・終了コード）
止める上限はあるか（回数・予算・時間）
人間が握る地点はどこか
1つでも答えられなければ、エージェントにはせず、その場の単発の指示で済ませる
質問1と2は「作る価値」と「作れるか」を分ける
週1回未満の作業は、作る手間のほうが大きくなります。手で頼めばよい仕事に1体を割り当てると、その1体の保守が新しい仕事になります。
質問2は、4つの中で一番落ちる質問です。「機械が合否を判定できる」とは、人が読まなくても合格・不合格が決まる形にできる、という意味です。僕がよく使う例は動画のテロップで、「読みやすいか」は判定できませんが、「2行になっていないか」は判定できます。2行なら不合格、1行に直るまで通さない。この形にできれば機械に任せられます。
業務を、機械が判定できる粒度まで分解できるかどうかが、エージェントにできるかどうかの分かれ目です。
質問3と4は「止め方」を先に決める
質問3の上限は、失敗から入れた条文です。2026年7月、調査の自動化で外部サービスの残高を一晩で使い切ったことがありました。上限が無く、失敗したら再試行する設計だったからです。以来、外部の資源を使う自動化は、上限と消費のペースを設計時に見積もり、止まる仕組みを先に置いています。
質問4は順番④で詳しく扱います。ここでは「取り返しのつかない操作の直前」と答えられれば十分です。
4つとも答えられた業務だけが、次の器の選定に進みます。 答えられなかった業務は作らない。これは失敗ではなく、正しい判断です。
順番②: 器の選定。最も単純で足りるものを選ぶ
器とは、AIエージェントをどんな形で組むか、です。僕の設計計画の雛形には最初に「どの器で作るか」を判定する欄があり、原則は1つ。最も単純で足りるものを選ぶ。 複雑さは、測って必要だと分かったときにだけ足します。
器の階段は4段。下から登る
単発の指示。1回の依頼文で終わる。週1未満の作業や、まず試す段階はここ
繰り返す指示の部品化。同じ依頼文に名前をつけて保存し、呼び出せるようにする。手順が固まった作業はここで足りることが多い
1本の流れ。取得→作成→検査→保存のように手順を固定して順に走らせる。毎朝決まった時刻に動かすものはここ
複数体の分担。調査役・執筆役・検品役のように役割を分け、成果を突き合わせる。成果が実証されてから登る段
自社では、2段目をClaude Codeの繰り返し指示の部品化として、3段目を毎朝の調査の自動化として、別記事に現物を置いています。最初の1体は、2段目か3段目で足りることがほとんどです。4段目から始めた1体を、僕は自社で1つも持っていません。
AIエージェント開発の選択肢。ノーコード・ローコード・コードはどう選ぶか
AIエージェント開発の解説では、ノーコード（画面操作だけで組む）・ローコード（一部だけ簡単な設定やコードを書く）・コード（プログラムで組む）の3分類がよく使われます。この分類は上位の解説記事から借りたもので、僕の発明ではありません。
僕の答えは、この3つのどれを選ぶかは順番②の後半であって、前半ではない、です。先に器の段を決め、その段を最も単純に実現できる手段を選ぶ。1段目・2段目はほぼノーコードで済み、3段目で「検査を通してから保存する」まで求めると設定や短いコードが要ることが多い。それだけです。ツールの名前や性能の優劣は、僕が実測していないので書きません。ChatGPT・Claude・Gemini・Copilotのどれで作っても、段の選び方は変わりません。
順番③: 合格基準を先に書く。普通・例外・過去の失敗の3件
器を決めたら、作り始める前に合格基準を3件書きます。僕の設計計画の雛形では、この3件が書けていない計画は未完成として扱います。
合格基準は、実装の前に3件書く。普通のケース、例外のケース、過去に起きた失敗の3件。それぞれに、入力の例・期待する振る舞い・機械的に判定できる合格の条件を書く。「あとで書く」を許さない。（自社の設計計画の雛形より）
3件の中身
普通のケース: いつもの入力で期待どおりの結果が出て、検査を通ること。例: 会議の録画1本から議事録と決定事項の一覧が保存され、決定事項が0件でないこと
例外のケース: 何かが欠けたときに、壊れずに正直に止まるか縮退すること。例: 音声が取れなかったら、空の議事録を保存せず「音声取得失敗」を記録して止まること
過去に起きた失敗: 一度起きた事故が二度と通らないこと。最初の1体では「その業務で過去に人がやらかしたこと」を1件入れます。例: 参加者名が名簿と一致しない議事録は保存前に止まること
なぜ「先に」なのか
作った後に基準を書くと、基準はできあがった挙動に合わせて甘くなります。先に書くと、基準が実装を導きます。
「機械が判定できる形」とは、人が読んで合否を決めるのではなく、検査が終了コードで合否を返す形にする、ということです。 終了コードとは、プログラムが終わったときに「正常に終わった（0）か、異常があった（0以外）か」を返す数字です。この数字を次の工程の前提にすると、人が見ていなくても不合格は先に進めません。
合格基準のうち1件を実際の指示文にどう書くかは、AIに仕事を任せるプロンプトの設計で完了・検品・上限の3点セットとして書いています。
順番④: 機械ゲートと人間ゲートはどこに置くか
ゲートとは、結果が次の工程に進む前に通る関門です。機械が判定する機械ゲートと、人が判断する人間ゲートの2種類があり、置く順番と場所が決まっています。
3段の置き方
機械ゲートが先に止める。順番③の合格基準を検査が判定し、終了コードが0でなければ次に進まない。人はここで呼ばれない
取り返しのつかない操作の直前だけ、人が押す。送信・公開・決済・削除のような戻せない操作の前に、1点だけ人間ゲートを置く
公開後24時間以内の事後レビュー。人が事前に全件見るのをやめる代わりに、出た結果を翌日までに人が見る。通知が届き、見た記録を残す
機械が先、人は後。人が押すのは、戻せない操作の直前の1点だけ。 この順にすると、人間の手間は「毎回の添削」から「1日1回の確認」に変わり、それでも事故は機械ゲートで先に止まります。
自社のブログの記事便では、機械ゲートの終了コードが公開の前提で、人間の事後レビューは公開後24時間以内です。2026年7月に決めた運用で、2026年9月時点も同じです。どの操作を「取り返しのつかない操作」とみなすか、被害範囲でどう線を引くかは、AI自動化のリスク設計に書いたので、ここでは繰り返しません。
順番⑤: 毎日回す運用。止まった記録は次の合格基準になる
作った1体は、毎日回して初めて育ちます。育て方は1つで、止まった記録を消さず、次の合格基準に昇格させることです。
止まった記録の昇格
止まったときの記録には、入力・何が起きたか・どこで止まったかが残っています。これは順番③の「過去に起きた失敗」の3件目そのものです。事故が1件起きるごとに、合格基準が1件増える。 これを回帰と呼びます。回帰とは、一度直した不具合が再発しないことを確かめる検査です。
自社の記事便には、こうして固定された合格基準が実際にあります。1つは、別の自動化で「計測の仮説を書かずに1か月回してしまい、効果検証ができなかった」事故を、記事便では「仮説・計測目標が空のまま公開しようとしたら止める」検査に写したもの。もう1つは、記事便の公開1本目で起きた「カバー画像が本文にも二重に表示された」事故（2026年7月19日）を、「カバー画像が本文に埋め込まれていたら止める」検査に固定したものです。どちらも2026年9月時点で、毎朝の便のたびに走っています。
止まった記録から、運用そのものが変わることもある
2026年8月上旬には、記事の企画在庫が尽きて4日間、便が止まりました。止まった記録を見て変えたのは検査ではなく運用で、「在庫が一定数を切ったら、実測データを根拠に企画を自動で補充してよい」という条文を追加しました。止まった記録は、検査だけでなく運用の設計も直します。
止まった朝は正直に気が重いんですが、記録を読むと「次はここに検査を1つ足せばいい」が必ず見つかります。消さずに残しておくのが、育てるいちばんの近道でした。
事故を1文の検査に言い換える手順はAI運用の再発防止に、改善を回す仕組み全体はループエンジニアリングにまとめています。
自社の実例。このブログの記事便はこの順番で作られた
読んでいただいているこのブログ自身が、上の順番で作った1体です。
2026年7月、僕はまず設計計画を書きました。最初の欄は「どの器で作るか」の適合判定で、企画→調査→執筆→画像→組み立て→検査→投稿という手順が予測できる作業だったので、3段目の「1本の流れ」を選びました。複数体の分担は成果が出てから、と計画に書いてあります。
次に合格基準を3件書きました。普通のケースは「1つのテーマから記事の一式ができて検査を通り、下書きが管理画面に届く」。例外のケースは「画像の生成が失敗したら、本文だけで縮退して完走し、劣化を正直に記録する」。過去の失敗は、前節の「仮説なしで公開しようとしたら止まる」です。この3件を書いてから、初めて作り始めました。
検証ゲートは検査の終了コードを公開の前提にし、人間は公開後24時間以内の事後レビュー。運用に入ってからは、止まった記録を合格基準に昇格させる自己改善の輪を回しています。適合判定、合格基準の先行、検証ゲート、自己改善ループ。この4つは、そのまま設計計画の節の名前です。
同じ雛形で書いた設計計画は、2026年9月時点で20件以上あります（社内記録）。現役の「1本の流れ」型の自動処理は9本です。件数だけを書いているのは、各件の成果や工数削減を実測していないものを、数字で装いたくないからです。
自分で作らない選択。外注・OSS・買う判断との分岐
4つの質問に答えられても、自分で作らない選択はあります。分岐は3つです。
既に同じ業務を解くサービスや、公開されているOSS（無償で公開され、誰でも使えるソフト）があるなら、まずそれを探す。2026年8月にXで広く読まれた投稿にも、初めて触った非エンジニアには「車輪の再発明」を知ってほしい、ゼロから作るとメンテと漏洩リスクを抱える、という趣旨のものがありました（出典は末尾）。僕も同意見です
自社に保守する人と時間が無いなら、外注する。ただし外注しても、4つの質問と合格基準3件は発注側が書きます。外注の線引きはAI自動化の外注に書いています
既製の「AI社員」型サービスを買う判断基準はAI社員の導入基準に、作った社内ツールを公開する・やめる線引きはバイブコーディングで作る社内ツールにまとめています
どの分岐に進んでも、4つの質問と合格基準3件は自社で書く。 ここを渡すと、納品物の合否を自社で判定できなくなります。
最初の1体を作る5ステップ
週1以上繰り返すか、機械が合否を判定できるか、止める上限はあるか、人間が握る地点はどこか。1つでも答えられなければ、その業務は単発の指示文にして終える
単発の指示→部品化→1本の流れ→複数体の階段で、最も単純で足りる段を選ぶ。ノーコードかコードかは、段を決めた後に手段として選ぶ
普通・例外・過去の失敗の3件を、入力の例・期待する振る舞い・機械が判定できる合格条件で書く。書けるまで実装に入らない
検査の終了コードを次の工程の前提にし、取り返しのつかない操作の直前だけ人が押す。公開後24時間以内の事後レビューを通知つきで運用に入れる
止まった記録を消さず、次の合格基準に加える。事故1件ごとに検査が1件増える運用にする
AIエージェントの作り方でよくある質問
作れます。ただし「動くものが作れる」と「業務で動き続ける」は別で、後者を決めるのは技術ではなく順番です。4つの質問に答え、合格基準を先に書けるなら、非エンジニアでも最初の1体は動き続けます。答えられない業務は、エンジニアが作っても動かなくなります。
1段目・2段目の器なら、すでに契約しているAIの範囲で追加費用なしに作れることが多いです。3段目以降は、AIの利用料に加えて、定時に動かす仕組みと外部サービスの費用が乗ります。僕の会社は既存のAIの契約の範囲で自社構築して運用しています（2026年9月時点）。金額の前に、質問3「止める上限はあるか」で予算の上限を決めるほうが、費用の事故を防げます。
順番①から⑤はどれで作っても変わりません。僕は自社ではClaude Codeを中心に使っていますが、器の段を決め、合格基準を先に書き、ゲートを置く順番はツールに依存しません。すでに社内で契約していて、業務のデータにつなぎやすいものから始めるのが合理的です。ツール間の性能比較は、僕が実測していないので断定しません。
1段目・2段目には不要です。3段目で検査の終了コードや定時実行まで組むと、簡単な設定やコードを読む場面が出てきます。ただし今は、そのコード自体をAIに書かせて、人は合格基準を書く側に立てます。学ぶなら、プログラミング言語より「合格基準を機械が判定できる形に分解する」考え方のほうが、最初の1体には効きます。
4つの質問に答えられ、2段目か3段目で足りるなら自作をおすすめします。保守する人と時間が無い、または既に同じ業務を解くサービスやOSSがあるなら、作らない・買う・外注するが正解です。どちらの場合も、4つの質問への答えと合格基準3件は自社で書いてください。外に出すと、納品物の合否を自社で判定できなくなります。
まとめ。作らない判断から始めて、止まった記録で育てる
自社業務のAIエージェントの作り方は、ツール選びではなく順番です。作らない判断の4つの質問に答え、最も単純な器を選び、合格基準3件を先に書き、機械ゲートを先に・人間ゲートを戻せない操作の直前に置き、毎日回して止まった記録を合格基準に昇格させる。
最初の1体は、小さくて、よく止まって、止まるたびに賢くなるものが正解です。自社の業務でどこから始めるか、4つの質問を一緒に埋めるところから相談したい場合は、お問い合わせからご連絡ください。
順番①の前に「どの業務を候補にするか」を洗い出せる「AIに任せてよい業務の棚卸しワークシート」を無料で配布しています。候補の業務を並べたうえで、本記事の4つの質問を1件ずつ当てると、最初の1体にする業務が決まります。
付録。合格基準3件の穴埋め雛形
対象の業務: ＿＿（週＿回。機械が判定する項目: ＿＿。止める上限: ＿＿回／＿＿円／＿＿分。人が握る地点: ＿＿の直前）
普通のケース: 入力＝＿＿ ／ 期待する振る舞い＝＿＿ ／ 合格条件＝＿＿が＿＿であること（検査が終了コード0を返す）
例外のケース: 入力＝＿＿が欠けている・失敗する ／ 期待する振る舞い＝＿＿を保存せず「＿＿」を記録して止まる ／ 合格条件＝空の成果物が保存されていないこと
過去に起きた失敗: 事故＝＿＿（＿年＿月） ／ 期待する振る舞い＝＿＿の場合は保存・送信の前に止まる ／ 合格条件＝同じ入力で検査が終了コード0以外を返すこと
事後レビュー: 公開・送信後＿時間以内に＿＿が確認し、確認した記録を＿＿に残す
出典
線引きを先に書きます。5つの順番、作る前の4つの質問、合格基準3件の型、器の階段、このブログの記事便の設計と事故の記録、設計計画20件以上・自動処理9本という件数は、僕の自社運用の記録（設計計画の雛形、自動化の規約、合格基準と検査の記録、定時実行の記録。いずれも社内記録・2026年9月時点）に基づく一次情報です。借りた部分は次の3つです。
Human-in-the-Loop（人が確認する工程を挟む考え方）は業界の一般概念で、上位の解説記事でも使われています。本記事の貢献は「機械が先に止め、人は戻せない操作の直前の1点と事後レビューだけ」という置き場所の指定です
ノーコード・ローコード・コードの3分類は、上位の解説記事（JAPAN AIラボ、マネーフォワード クラウド、cloudpackの各AIエージェント解説。リンクは省略・2026年9月6日確認）の分類を借りました。本記事は上位が扱っていない「作る前の判断」と「作った後の運用」の順番に絞りました
@kajikent の投稿（x.com）（2026年9月3日確認）: 非エンジニアがAIで開発を始めたあとの感想は「AIがあっても依然として難しい」であり、職業不要論はデモ的にツールを使っているだけ、という趣旨
@ds_nakajima の投稿（x.com）（2026年9月3日確認）: 初めて触った非エンジニアには「車輪の再発明」を知ってほしい、自前開発はメンテと漏洩リスクを抱える、という趣旨
@ClaudeDevs の投稿（x.com）（2026年9月3日確認）: 商用エージェントの設計をOSSとして公開した、という趣旨。「作れる」側の供給が増える一方で、最初の1体を作る順番は語られていない、という本記事の出発点に用いました
この記事が役に立ったらシェア
Related
