ローカルAIエージェントの業務ワークフロー：GDPR & EU AI Act準拠ガイド 2026

クイックファクト

• アーキテクチャ： Ollama または vLLM + tool-calling対応モデル + エージェントランタイム（Cline または Goose+MCP）+ 監査ログ + RAGストア、すべて管理者のインフラ上。
• カバーするワークフロー： 文書取り込み、メールトリアージ、議事録要約、コンプライアンスレポート、請求書処理。
• 5テンプレートのEU AI Act分布： Limited-risk 4件、High-risk 1件（HRスクリーニング用途時）、禁止 0件。
• DPIA基準： High-riskは必須、その他は条件発動（第35条基準）。特別カテゴリーデータを扱うワークフローについては実施を推奨。
• ハードウェアサイジング： Gemma 4 27B と Qwen3 32B は Q4_K_M で 24 GB VRAM に収まる。GLM-5.1 32B と Llama 3.3 70B は十分なコンテキスト確保のため 48 GB+ を推奨。
• 監査ログ保存： GDPR第30条記録要件が下限。業界別規則（金融、医療）で延長。多くのエンタープライズ環境で6年が安全なデフォルト。
• コスト： APIコストはゼロ。ハードウェアは20名以上のチームで6〜12ヶ月でエンタープライズSaaS AIサブスクリプションコストを回収。

ローカルAIエージェントが業務チームにもたらすもの

• 定義： モデル + ツール表面（ファイルシステム、データベース、メール、カレンダー、社内API）+ 書き込みごとの承認ゲート = エージェント。モデルが提案、エージェントランタイムが実行、人間が状態を変更するもの・ネットワークを離れるものすべてを承認。
• 自動化ツールとの区別。 n8n、Zapier、Make.comは決定論的ワークフロー——明示的トリガー、明示的分岐、明示的アクション。エージェントは非決定論的：モデルが入力と会話状態に基づき、どのツールをどの引数で呼ぶか決定。経路が固定なら自動化、入力ごとに変わるならエージェント。
• チャットアシスタントとの区別。 チャットアシスタントは質問に答え、エージェントはアクションを実行。ChatGPT形式の「このメールを要約して」はテキストを返す；エージェントは受信箱を読み、メッセージを分類し、返信ドラフトを作成し、承認待ちにキューイング。表面が異なり、リスクプロファイルも異なる。
• 「ローカル」が業務ワークフローで特に重要な理由： データレジデンシーが立証可能（バイトはネットワークを出ない）、監査トレイルがエンドツーエンド（同一ログがモデル呼び出し・ツール呼び出し・結果を記録）、チェーン内に第三者サブプロセッサーが存在しない。アーキテクチャ自体がリスクカテゴリーを丸ごと除去するため、コンプライアンス論理は自明となる。
• ローカルエージェントが組織内で適合する場所： 個人情報（GDPR）、従業員データ（Betriebsrat）、第三者機密データ（NDA、§203 StGB）、または規制対象業務データ（金融、医療、法務）を扱うワークフローすべて。公開データのみを扱うワークフローでは、ローカルエージェントは改善をもたらしません——その場合、クラウドエージェントが通常より高速で安価。
• 実用化を可能にするプロトコル層については MCPでOllamaをデータベース・APIに接続：ローカルエージェントセットアップ 2026 を参照。

5つの業務ワークフローテンプレート

• 1. 文書取り込みと分類。 トリガー：PDFまたはスキャンが監視フォルダまたはメールに到着。ツール：ファイルシステム（読み取り）、OCR（必要時）、分類モデル、データベース（書き込み）。モデル：tool-callingと構造化出力にGemma 4 27BまたはQwen3 32B。承認パターン：読み取りと分類は自動、文書が個人を言及する場合のルーティングは手動。AI Actレベル：Limited-risk。DPIA：条件発動。
• 2. ドラフト返信付きメールトリアージ。 トリガー：監視受信箱への新着メッセージ。ツール：IMAP/Graph API（読み取り専用）、分類モデル、ドラフト保存（書き込み）、通知。モデル：トリアージはLlama 3.2 3Bで十分、ドラフト生成はGemma 4 27B。承認パターン：分類とドラフトは自動、送信は手動（常時）。AI Actレベル：Limited-risk。DPIA：条件発動；受信箱が従業員データを扱う場合は必須。
• 3. 議事録要約とアクション抽出。 トリガー：トランスクリプトがストレージに到着（Whisperまたはベンダー）。ツール：ファイルシステム（読み取り）、要約モデル、抽出モデル、出力先（API経由でNotion/Jira/社内wiki）。モデル：1時間級トランスクリプトの長文コンテキスト（128K）にQwen3 32B。承認パターン：要約は自動、外部システムに投稿されるアクションアイテムは手動。AI Actレベル：Limited-risk；トランスクリプトごとに同意取得を確認。
• 4. コンプライアンスレポート生成。 トリガー：スケジュール（月次、四半期）。ツール：データベース（読み取り）、レポートテンプレート保存、レポートレンダラー、レビュアー通知。モデル：GLM-5.1 32BまたはLlama 3.3 70B——長文コンテキスト、構造化出力、低ハルシネーション。承認パターン：データ抽出は自動、公開レポートは手動。AI Actレベル：Limited-risk；元データソースが文書化された適法根拠を持つことを確認。レポート構造を安定化するため 構造化出力とJSONモード と組み合わせ。
• 5. 請求書処理と検証。 トリガー：請求書が経理受信箱またはAPフォルダに到着。ツール：ファイルシステム（読み取り）、OCR、ERP統合（POおよびベンダー読み取り）、例外キュー（書き込み）。モデル：tool-callingにGemma 4 27B、非標準レイアウトの請求書にはQwen3 32B。承認パターン：抽出とPO照合は自動、例外（不一致、新規ベンダー、高額）は手動。AI Actレベル：Limited-risk。DPIA：通常は発動せず。
• 5つに共通するパターン： 読み取りステップは自動承認、外部システムや個人の権利に影響する書き込みステップは手動承認。監査ログがすべての判断を記録。

業務エージェントのEU AI Act分類

• Limited-risk（多くのテンプレート）： 透明性義務。AI生成のメールや要約を受け取るユーザーは、AIが関与したことを知る必要があります。メッセージ内の明確な表示と、システムのエンドユーザー向けドキュメントへの一行記載で通常は満たせます。適合性評価は不要。
• High-risk（特定ユースケース）： 完全な適合性評価、EUデータベースへの登録、市販後モニタリング、一部のサブカテゴリーでは認証機関。業務チームでHigh-riskに該当するパターンは、HRスクリーニング（CVランキング、候補者スコアリング）、与信判断、給付資格判定、公共サービスへのアクセス。AI Act附属書IIIが操作的リストです。
• 禁止（展開不可）： 公共空間でのリアルタイム生体認証（法執行向けの限定例外あり）、自然人のソーシャルスコアリング、脆弱性を狙う操作技術、職場での感情認識（医療・安全のための限定例外あり）、プロファイリングに基づく予測警察活動。
• 5テンプレートの実用的なワークフロー → レベルマッピング： 文書取り込み（Limited-risk）、メールトリアージ（Limited-risk）、議事録要約（Limited-risk；同意確認）、コンプライアンスレポート（Limited-risk）、請求書処理（Limited-risk）。5つの基本テンプレートはすべてLimited-risk；同じテンプレートをHRスクリーニングや与信判断に転用すると、用途からHigh-risk義務を継承。
• プロバイダーvsデプロイヤーの区別が重要。 モデルを他者に販売する製品に組み込む場合、プロバイダー（より多くの義務）。自己のためにシステムを運用する場合、デプロイヤー（義務は少ないが実在）。社内専用ローカルエージェントは通常デプロイヤーに該当。
• 新規ワークフロー向けアクション項目： 展開承認前に分類してください。分類は単一の決定（Limited / High / 禁止）と書面正当化で、DPOまたはコンプライアンスリーダーが署名し、AIシステムの技術ファイルに保管します。

エージェントワークフロー向けGDPR管理

• 1. 適法根拠（第6条）。 展開前にどの根拠が適用されるかを文書化——同意、契約、法的義務、正当な利益、生命に関わる利益、または公的任務。多くの業務エージェントワークフローは契約（従業員/顧客関係）または正当な利益（文書化されたバランステスト付き）で運用。特別カテゴリーデータ（健康、生体、政治的見解）には第6条根拠の上に第9条条件が必要。
• 2. データ最小化（第5条(1)(c)）。 エージェントはワークフローに必要な個人情報のみを参照すべきです。実用上：モデルではなくRAGレイヤーでチャンクとフィルタリング。1セクションのみ関連する場合、文書全体を会話にストリーミングするのは避けます。タスク完了後、個人情報を含む中間プロンプトの保持は避けます。
• 3. 目的制限（第5条(1)(b)）。 エージェントは再評価なしにタスク横断的に再目的化すべきではありません。請求書処理用に承認されたワークフローが従業員業績レビュー業務を静かに吸収することはできません——これは新しい目的、新しい適法根拠、新しいDPIA判断です。
• 4. 処理のセキュリティ（第32条）。 保存時暗号化、ワークスペースへのアクセス制御、不変監査ログ、「モデルが生成すべきでない出力を生成した」を含むインシデント対応計画。ローカルアーキテクチャはここで多くをカバーしますが、すべてをカバーすると仮定しないでください。
• 5. 監査ログ。 エージェントアクションごとの最小ログフィールド：タイムスタンプ、ユーザー/開始者、モデル識別子とバージョン、入力ハッシュ、ツール呼び出しと引数、出力ハッシュ、承認者（手動承認時）。Append-only保存；整合性保護（ハッシュチェーンまたは署名済みログ行）。
• 6. DPIA（第35条）。 ワークフローが重大な影響を伴う個人情報の体系的処理、規模を持つ特別カテゴリーデータ、またはAI Actの下でのHigh-riskを含む場合に必須。それ以外は条件発動。DPIAは管理策、残存リスク、DPO署名を文書化。
• 基盤となるデータ側アーキテクチャについては プライベート業務データ向けローカルRAG を参照——RAG管理策が同一の監査パイプラインを供給。
• プロンプトと出力管理の上層については 本番環境におけるプロンプトガバナンス と プロンプトインジェクションとセキュリティ を参照。

ドイツ固有事項：Betriebsrat共同決定と§203 StGB

• Betriebsrat共同決定（BetrVG §87(1) Nr. 6）。 従業員の行動や業績を監視する技術システムは共同決定を発動します。「監視」はドイツ労働裁判所により広く解釈されます——従業員のメールを分類するエージェントや従業員ミーティングを要約するエージェントはこれに該当します。Betriebsratは展開後ではなく、設計時に関与する必要があります。このステップを飛ばしたことで、エージェント展開が事後的に無効化された事例があります。
• 実用上の含意： 従業員データを処理するワークフロー——たとえ受動的でも、即時出力が従業員自身の利益のためでも——を展開する前にBetriebsratと協議してください。合意（Betriebsvereinbarung）はシステムの技術ファイルの一部となります。早期に関与すれば多くのBetriebsratは建設的；遅く関与するとほぼ建設的ではありません。
• §203 StGB職業守秘義務。 弁護士、医師、税理士、会計士、その他特定職業は依頼者情報の不正開示について刑事責任を負います。「補助者」の例外（§203(3)）は社内スタッフをカバーしますが、外部サービスプロバイダーは自動的にカバーしません。クラウドLLMは外部サービスプロバイダーです；§203対象法律事務所がローカルスタックに移行した法的核心がこれです。
• 実用上の含意： §203対象職業については、純粋にローカルなアーキテクチャは選好ではなく、ワークフローが存在を許される前提条件です。エージェントベンダー（存在する場合）との契約には§203準拠条項が含まれる必要があります；技術ファイルには依頼者データが事務所インフラを離れないことが文書化される必要があります。
• オーストリアとスイス： オーストリアは§203を密接に反映（StGB §121）；スイスの守秘義務（StGB CH 第321条）はさらに広範。アーキテクチャ的結論は同じ——純粋にローカル、機密職業データに例外なし。
• 同一管理者でのデータ側コンプライアンス画像については プライベート業務データ向けローカルRAG を参照——RAGとエージェントスタックは監査ログとアクセス制御層を共有。

業務エージェントに適切なモデルを選択

• **Gemma 4 27B（gemma4:27b）。** 2026年5月時点で最高の汎用tool-caller。16 GB ユニファイドメモリまたは Q4_K_M で 24 GB VRAM に収まる。文書取り込み、メールトリアージ、請求書処理で信頼性が高い。連鎖tool-callでやや保守的——各ステップが明示的承認を伴う業務ワークフローに適合。
• **GLM-5.1 32B（glm5:32b）。** デフォルトで128Kコンテキスト。Tool-call信頼性が強い。長い入力（コンプライアンスレポート、1時間級議事録）のコンプライアンスレポートと議事録要約に最適。コンテキスト無制約で Q4_K_M で 24 GB+ VRAM が望ましい。
• **Qwen3 32B（qwen3:32b）。** バランスが良く、複数ステップ計画で非常に信頼できる。Gemma 4が保守的すぎる場合の良いフォールバック。デフォルトで32Kコンテキスト；多くの業務タスクに十分。
• **Llama 3.3 70B（llama3.3:70b）。** 最高の天井、最重量ハードウェア。Q4_K_M で 48 GB+ VRAM または 64 GB ユニファイドメモリ。速度より信頼性が重要なコンプライアンスレポートと例外処理に使用。
• **Llama 3.2 3B（llama3.2:3b）。** 高ボリュームトリアージ向けの軽量選択。8 GB VRAMで快適に動作。「これはカスタマーサポート / 営業 / スパムか」には十分；返信ドラフトには不十分。ドラフトステップには27B+モデルとペアリング。
• Mistral Large。 純粋ローカルが過剰でUSクラウドが選択肢にないハイブリッド構成向けのEUホスト型代替。MistralのEUエンドポイント経由でDPA設置済みで運用；データはEU管轄内に滞留。
• Tool-callingで避けるべきもの： 本番作業向けに7B未満のもの、明示的tool-callトレーニングがない汎用モデル、小型モデルでQ4_K_Mより厳しい量子化。症状は不正なtool-call、ハルシネーション引数、停止したエージェントループ。
• 対面比較データについては Tool-Calling向け2026年最高のローカルモデル を参照。同じモデルのVRAMとハードウェアサイジングについては ローカルLLMハードウェアガイド2026 を参照。

業務利用向けエージェントスタック比較

• Cline + Ollamaを選択 チームが開発者中心で、ワークフローがVS Code内に収まる場合。インストールフリクション最小、動くエージェントへの最速ルート。
• Goose + MCPを選択 ワークフローがヘッドレスサーバー（スケジュールされたコンプライアンスレポート、フォルダ監視取り込み）で実行される場合、IDEがない。
• n8n + Ollamaを選択 ワークフローがモデルステップ1〜2の決定論的形を持つ場合。n8nのHuman-in-the-loopノードがカスタムUIなしで承認ゲートを提供。
• カスタムLangGraphを選択 ワークフローの形が上記と本当に互換性がない場合のみ。構築労力は実在；監査トレイルと承認ゲートのコードはあなたの担当。
• これらのスタック横断の正直な信頼性比較については ローカルAIエージェント2026：実際に動くもの（そしてまだ失敗するもの） を参照。

EU業務ワークフローでローカルエージェント展開時のよくある失敗

• 失敗1：DPIAなしで展開。 特別カテゴリーデータを扱うワークフロー、または個人について判断するワークフローはDPIAが必要です。DPIAは短い——ほとんどのエージェントワークフローで4〜8ページ——ただし必須で、監督機関が最初に求めるものです。展開後ではなく、展開前に作成してください。
• 失敗2：機密文書にクラウド接続エージェントを使用。 エージェントランタイム、監査ログ、または埋め込みストアが他者のクラウドにある場合、ローカルモデルだけでは不十分です。アーキテクチャはエンドツーエンド；チェーン内の1つのクラウド依存がローカルのみの議論を破ります。
• 失敗3：書き込みまたは送信アクションに承認ゲートなし。 エージェントは読み、分類し、ドラフトし、送信します。送信ステップは、モデルがどれだけ信頼できる過去であっても、人間が毎回承認すべきステップです。自動送信エージェントは、規制機関があなたについて聞く方法です。
• 失敗4：個人情報と業務データを単一ワークスペースで混在。 エージェントの作業ディレクトリとベクトルストアはワークフローごとにスコープすべきで、共有すべきではありません。クロスコンタミネーションは目的制限に違反；回復は高価。
• 失敗5：監査ログをスキップ。 「モデルの会話履歴から再構築できる」は監査ログではありません。Append-only、ハッシュチェーン、関連保存期間ごとに保持、データ主体アクセス要求ハンドラーがクエリ可能——これがバーです。

出典

• EU AI Act統合テキスト（artificialintelligenceact.eu） — 規則の公式トラック集約；附属書IIIが操作的High-riskリスト。
• GDPR全文（gdpr-info.eu） — エージェント設計に操作的なのは第5条、6条、25条、32条、35条。
• NIST AI Risk Management Framework — 非EU、非拘束だが、GOVERN / MAP / MEASURE / MANAGEの構造は監査準備チェックリストとして有用。
• EDPB Guidelines 03/2018 自動個別意思決定について — 個人について判断するワークフローに操作的；GDPR第22条とAI Actの両方で重要。
• 経済産業省 AI事業者ガイドライン — 日本のエンタープライズ展開向けガバナンスフレームワーク；個人情報保護法（APPI）と整合。

よくある質問

関連記事

• プライベート業務データ向けローカルRAG — 同じ監査パイプラインを供給するGDPR準拠データ側アーキテクチャ。
• MCPでOllamaをデータベース・APIに接続：ローカルエージェントセットアップ2026 — ファイルシステム、データベース、ブラウザ、GitHubツール用のプロトコル層。
• ローカルAIエージェント2026：実際に動くもの（そしてまだ失敗するもの） — 上記推奨4ランタイム横断の正直な信頼性比較。
• ZapierをローカルAIエージェントで置き換える — エージェントスペクトルの決定論的形側のn8n + Ollamaワークフローテンプレート。
• Tool-Calling向け2026年最高のローカルモデル — 本ガイド推奨モデルの対面ベンチマーク。
• ローカルLLMセキュリティ・プライバシーチェックリスト — これらのワークフローを実行する同じハードウェアの管理層。