ノーコードでAIエージェントを作る方法：実践ステップガイド
AIエージェントは数時間で、コードを書かずに作成できます。ただし手順を守ることが条件です。業務の定義、モデル選定、指示文の作成、テスト。この工程が、話題作りだけのツールと実際に業務を回す仕組みとの分かれ道になります。
1. AIエージェントとチャットボット、アシスタントは別物
チャットボットは質問に答えるだけ。アシスタント（コパイロット）は提案する。AIエージェントは行動する：目標を受け取り、使うツールを自ら選び、実際のアクションを実行し（メール送信、CRM更新、書類の読み取り、APIの呼び出しなど）、結果を報告する。三者の違いは度合いの差ではなく、性質そのものの違いである。
三つを混同すると時間を失う。「答えてほしい」場面に「答えるだけ」の設定をしたエージェントを当てても、逆に「動いてほしい」場面に「答えるだけ」のエージェントを使っても、必ず期待外れになる。ツールを開く前に自問する：システムに答えてほしいのか、動いてほしいのか。この答えが、採用するアーキテクチャ、選ぶプラットフォーム、用意すべき安全策を決める。
AIエージェントは三つの要素で構成される。言語モデルが指示を処理し判断を生み出す。ツール（API、コネクタ、ファイルアクセス）が外部システムへの操作を可能にする。メモリ（永続的か否か）が過去のやり取りの文脈を保持する。このうちどれか一つを外すと、エージェントはアシスタントや単純なチャットボットに戻ってしまう。
2. 技術ではなく、業務内容から出発する
途中で放棄されるエージェントの多くは、同じ理由でつまずく。作り手が業務内容より先にツールを選んでしまったケースだ。何かを開く前に、一文で書いてみる。「Yを元に、エージェントにXをしてほしい。そしてZを報告してほしい」。具体例：「自社の料金表PDFを元に、顧客からの価格についての質問に答え、対応が難しい案件は自分に転送してほしい」。
この一文が書けないなら、まだエージェントを作る段階ではない。最初のエージェントに向いているのは、ルールが決まっている繰り返し業務で、出力形式が明確なものだ。「マーケティング全般を任せるエージェント」のような曖昧な計画は、どんなツールを使っても失敗する。まず小さく始めて価値を示し、そこから広げていく。
最初のエージェントに適した業務かどうかは、三つの基準で見分けられる。週に何度も発生すること。例外の少ない安定したルールに従うこと。結果を人が一分以内に検証できること。三つが揃えば良い候補。一つでも欠けるなら、設定に入る前に対象業務を絞り込んだほうがいい。
3. エージェントを動かすモデルを選ぶ
モデルはエージェントの動力源であり、動力源には違いがある。Claudeは長い指示を保持し、簡潔な日本語文を生成する。GPT-4oは最も幅広いツール群を備え、OpenAIが2025年10月に発表したノーコードのビジュアルインターフェース「AgentKit」に標準対応している。Geminiは大容量の文書やメディアの処理に強い。Mistralは低コストで大量処理に向き、データを欧州でホストする点を重視する企業に選ばれている。Copilot Studioは、日々の業務がWordやExcel中心の場合に威力を発揮する。
評判だけでモデルを選ばない。自社の業務から実際の事例を三つ選び、同じ指示で二つか三つのモデルに投げ、出力を比較する。GPTProのようなマルチモデル対応のインターフェースを使えば、この比較検証が十分間で済む。個別に三社へ登録する手間はかからない。
利用コストも計算に入れる。1日100件のリクエストを高性能モデルで処理すると、月額コストがまとまった金額になる場合がある。モデルを固定する前に処理量を見積もる。処理量が多くルールが単純な業務には、軽量で低コストなモデルで十分なことが多い。高性能モデルは複雑な業務や頻度の低い業務に絞って使う。
4. 崩れない指示文（システムプロンプト）を書く
指示文（システムプロンプト）は、エージェントの人格であり規則でもある。四つのブロックに分けて構成する。役割（エージェントが何者で、誰のために働くか）、規則（すること、断ること、口調）、フォーマット（求める回答の正確な構造）、そして例（実際の優れたやり取りから抜き出した理想的な回答例を二、三個）。
よくある失敗が二つある。一つは「丁寧で役立つ対応をしてください」といった曖昧な指示。何も制約していないのに等しい。もう一つは、失敗ケースを想定していないこと。「用意された資料に情報がない場合は、その旨を伝え、担当者への引き継ぎを提案する」など、分からないときの振る舞いを明示的に指示する。この一文だけで、作り話のような回答の大半を防げる。
見えにくい四つ目の落とし穴は、指示同士の矛盾だ。「常に三文以内で答える」という規則と「各手順を詳しく説明する」という規則が同時に存在すると、エージェントは自分の判断で調整し、結果が予測できなくなる。テストの前に指示文を読み直し、矛盾がないか確認する。短くて一貫した指示文は、長くて曖昧な指示文に勝る。
5. 汎用知識ではなく、自社データを渡す
モデルは既定では学習データから答える。汎用的な知識であり、時に古く、自社の業務には特化していない。役に立つエージェントは自社の資料（料金表、社内手順書、FAQ、実際の対応文例など）から答える。これらをエージェントの設定に取り込み（実務者はこれをRAG、検索拡張生成と呼ぶ）、指示文でその資料に基づいて回答するよう明記する。
小さく始める。整理された三から五つの資料は、矛盾の多い四十のファイルよりも価値がある。二つの資料が矛盾していると、エージェントの判断は予測不能になる。まず整理し、それから取り込む。入力データの質が、出力される回答の質を決める。
資料の形式も内容と同じくらい重要だ。OCR処理されていないスキャンPDFはエージェントには読めない。セル結合の多いExcel表は誤った抽出を招く。Markdown、整形の少ないWord、複雑な書式のないCSVなど、構造化されたテキスト形式を優先する。資料を取り込む前に、テキストエディタで開いて内容がきちんと読めるか確認する。
6. 不機嫌な顧客になったつもりでテストする
「こんにちは、料金を教えてください」のような穏やかなテストでは何も証明できない。対象外の質問、規則に反する要求、曖昧なメッセージ、不完全な資料、エージェントに権限のない割引要求など、困る場面を試す。実際の履歴から選んだ十件程度の事例で、大半の弱点が見えてくる。
逸脱が見つかったら、進行中の会話ではなく指示文を修正する。会話中の修正は次のセッションで消えてしまう。指示文の修正はすべての今後のやり取りに反映される。対象範囲を絞ったエージェントなら、通常三、四回のやり直しで安定する。
すべてのテストと結果を簡単なファイルに記録する。この記録には二つの用途がある。後で指示文を変更した際に問題の原因をすぐ特定できること、そして高リスクなエージェントに求められる文書化の土台になることだ。最初のエージェントからこの習慣をつけておけば、後から履歴を再構築する手間を避けられる。
7. GPTPro、n8n、Make：どのエージェントにどの道具か
会話型エージェント（利用者の要求に応じて答える、書く、分析する）は、GPTProで数ステップ、コードなしで作成できる。自社の事例でモデルを比較できるという利点もある。個人利用や小規模チームの大半のニーズにはこれで十分だ。
一方、バックグラウンドの自動化（メールボックスの監視、CRM内でのアクション発動、人の手を介さないシステム連携）はn8nやMakeのような道具の領域になる。Makeは2025年4月に「Make AI Agents」を発表した。自然言語で目標を理解し、100%ノーコード環境でワークフローをリアルタイムに調整できるエージェントだ。n8nも2026年8月に独自の「n8n Agents」を投入した。一度定義したエージェントを、チャット、ワークフロー、Slack、スケジュール実行など複数の場面で再利用できる仕組みだ。多くの企業は両方を組み合わせている。対話的な作業はGPTPro、裏側の配管作業はn8nやMakeという分担だ。
選び方は単純だ。誰がエージェントを起動するのか。人が質問を投げる形ならGPTProで十分。メール受信、CRMのレコード更新、時刻指定の実行などシステム側のイベントが起点なら自動化ツールが必要になる。LINE WORKSやChatworkの通知をトリガーにする、といった使い方も同じ発想だ。両方のケースは同じ組織内で、別々の範囲で共存できる。
8. 個人情報保護法とAI Act：導入前に知っておくべきこと
日本国内でAIエージェントを運用する際は、個人情報保護法（APPI）と、その監督機関である個人情報保護委員会（PPC）のガイドラインが基本の拠り所になる。加えて、取引先や利用者にEU圏の関係者が含まれる場合は、2026年8月2日から適用が始まったEUのAI Actも視野に入れる必要がある。同規則は、利用者がAIシステムと対話していることを明示することを義務付けており、生成されたコンテンツにもその旨の表示を求めている。自社サイトのサポート用チャットボットも対象になり得る。
リスクの水準は、エージェントの自律性ではなく用途で決まる。メール文の下書きを作るエージェントは限定リスクにとどまる一方、採用選考の絞り込みや営業スコアリングを行うエージェントは、AI Actでは高リスクに区分され、人による監督、追跡可能性、文書化が求められる。フランスのCNILとCIANumは2026年7月、エージェント型AIと個人データに関する留意点をまとめた資料を公表し、永続的な記憶や複雑な処理連鎖に伴うリスクを指摘している。この論点は国内でエージェントを設計する際にも参考になる。導入前には、利用するSaaSプラットフォームとのデータ取扱いに関する契約を確認し、処理するデータを必要最小限に絞り、影響の大きい判断には人によるチェック工程を設けておくことが望ましい。
永続的なメモリには特に注意が必要だ。セッションをまたいで履歴を保持するエージェントは、時間とともに個人データを蓄積していく。利用するプラットフォームの保存期間ポリシーを確認し、個人情報保護法の趣旨に沿った保存期間を定め、要求に応じて削除できる仕組みを用意しておく。この点は前述のCNIL・CIANumの資料でも明示的に指摘されている。
コードを書かずにAIエージェントを作る工程は五つに要約できる。対象業務を明確にする。自社の事例でモデルを検証する。失敗ケースを含めて指示文を構成する。自社資料を文脈として渡す。稼働前に厳しくテストする。しっかりした最初のエージェントには、半日ほどを見込んでおく。
出発点として最適なのは、単純で頻度の高い業務だ。毎日20分の作業を減らしてくれる最初のエージェントが、その後に続くすべての取り組みの根拠になる。GPTProでは、コードを書かずに、業務に合ったモデルを選んで設定できる。
よくあるご質問
コードを書かずに本当にAIエージェントは作れるのか
作れる。ただし対象範囲を正しく選ぶことが条件になる。GPTPro、Make AI Agents、OpenAIのAgentKitといった道具を使えば、自然言語での設定だけでエージェントを構築できる。「コードなし」は「方法論なし」ではない。指示文の作成、資料選定、テストは依然として欠かせない。コードなしで作っても、設定が甘いエージェントは、雑にコーディングされたエージェントと同じくらい機能しない。
AIエージェントとチャットボットは何が違うのか
チャットボットはスクリプトやモデルに沿って質問に答える。AIエージェントは行動する：目標を受け取り、使うツールを選び、実際のアクション（CRM更新、メール送信、資料の読み取りなど）を実行し、結果を報告する。違いは運用面にある。エージェントは自社システムに実際の変化を起こせるが、チャットボットは起こせない。
最初の稼働可能なエージェントを作るのにどれくらい時間がかかるか
対象範囲が明確（一つの業務、明快なルール、整理された資料）であれば、半日程度で最初の安定したエージェントが作れる。時間の大半は指示文の作成と限界ケースのテストに使われ、ツール自体の設定にはあまりかからない。範囲が曖昧だったり資料同士が矛盾していると、この期間は大きく延びる。
AIエージェントを導入する際、個人情報保護にどう対応すればよいか
基本の対応は三つ。利用するSaaSプラットフォームとのデータ取扱いに関する契約を確認すること、エージェントが扱う個人データを必要最小限に絞ること、利用者にAIシステムと対話していることを伝えること（EU圏の利用者に対しては2026年8月2日以降、AI Actの義務対象になる）。高リスクなエージェント（人事選考、スコアリングなど）には、人による監督と判断の追跡可能性が求められる。2026年7月のCNIL・CIANumの資料は、エージェント型AI特有の留意点を詳しく示している。国内では個人情報保護委員会（PPC）のガイドラインも併せて確認したい。
AIエージェントを作るには技術的な知識が必要か、業務担当者だけでもできるか
業務担当者だけでも、ノーコードのプラットフォームを使えば会話型エージェントを作成・運用できる。業務知識があることはむしろ強みで、的確な指示文を書き、正しい限界ケースをテストできる。技術者が必要になるのは、独自CRMとの連携や複数システムをまたぐワークフローなど複雑な統合、あるいは正式な文書化が求められる高リスクなエージェントを扱う場面だ。
