No English page yet. Showing the Japanese source.
AI業務パターン・カタログ
記事状態: 公開 · 最終確認: 未確認
要点
AI業務パターンは、特定製品の機能名やプロンプト例ではなく、「何を正本として、どの入力から、どの権限で、どこまでAIに任せ、誰が承認し、何をもって完了とするか」を再利用可能な型として記述する。
現在の判断
AI業務パターンは、特定製品の機能名やプロンプト例ではなく、「何を正本として、どの入力から、どの権限で、どこまでAIに任せ、誰が承認し、何をもって完了とするか」を再利用可能な型として記述する。
どこまで当てはまるか
AI業務パターン・カタログ
詳しく理解する
Pattern schema
以下のschemaは PROPOSAL であり、provider仕様の必須schemaではない。
- PATTERN_ID / BUSINESS_INTENT
- TRIGGER / INPUT_ARTIFACT
- AUTHORITATIVE_SOURCE
- AI_ROLE
- ACTION_CLASS = READ / DRAFT / WRITE / EXECUTE
- REVERSIBILITY = reversible / compensatable / irreversible
- STATE / CHECKPOINT
- TOOLS / CONNECTORS
- PERMISSION_SCOPE / IDENTITY
- HUMAN_GATE / DECISION_AUTHORITY
- OUTPUT_ARTIFACT / DESTINATION
- EVAL / ACCEPTANCE_CRITERIA
- AUDIT / PROVENANCE
- FAILURE_MODE / RETRY / RECOVERY
- COST / LATENCY / MODEL_ROUTING
- IMPLEMENTATION_TOPOLOGY
Core patternはprovider非依存とし、provider mappingとorganization overlayを別層にする。製品名、model名、preview feature、plan/region availabilityは PRODUCT_VOLATILE として扱う。
Initial pattern cards
A. 調査
ACTION_CLASS: READ中心。 複数sourceからevidence/provenanceを保持してsynthesisする。主なfailureは引用不一致、freshness不足、source権限誤認、unsupported inference。acceptanceはcitation support、coverage、freshness、unsupported claim率で確認する。
B. 編纂
ACTION_CLASS: READ + DRAFT/WRITE。 正本と変更対象を分離し、diff/version/revision、構造保持、rollbackを持つ。acceptanceはrequired-change coverage、unrequested diff、structure preservation、revision/recoveryで確認する。
C. 監査
producerとcriteriaを分離し、evidence locator付きでPASS/FAIL/UNKNOWNを残す。AI自己評価だけでcloseしない。acceptanceはlabeled fixtureに対するFP/FN、evidence locator再現性、UNKNOWN適切率を用いる。
D. 会議
transcript/audioからsummary/action itemsを生成する。取得前にpermission、consent、retention、meeting expiry等のgateを確認する。read-onlyに見える処理でもidentity/permission/retention条件を省略しない。
E. メール
DRAFTとSENDを別patternにする。SENDは外部作用であり、宛先、本文、添付、機密性、最終承認を別gateにする。AIへ閲覧可能であることと外部送信可能であることを同一視しない。
F. 表処理
schema/range/formula/typeを明示し、自然言語の「表を直す」を無境界writeへ変換しない。cell/range validation、formula preservation、row count、key integrity等のdeterministic checkをAI自己評価より優先する。
G. データ移植
ACTION_CLASS: WRITE/EXECUTE。 source→target mapping、idempotency、checkpoint、retry、duplicate detection、reconciliation、dry-run/rollbackを持つ。件数一致だけを成功条件にせず、retryによる重複side effectをfailure envelopeへ含める。
H. コード保守
repository scope→plan/branch→change→tests→diff→PR→review→mergeを分離する。変更生成能力とmerge authorityを同一視しない。branch/ruleset、CI、secrets、Actions approval、review/merge authorityをgateとして扱う。
実装・運用
workflow / agent / multi-agentは業務patternそのものではなく実装方式として分離する。
固定分解可能な仕事にはprompt chaining、入力分類が明瞭ならrouting、独立subtaskならparallelization、動的分解が必要ならorchestrator-worker、明確な評価基準がある反復改善ならevaluator-optimizer等を候補にできる。ただしこれはpatternから一意に決めず、実測evalで正当化する。
multi-agent採用時はsingle-agentまたはfixed-workflow baselineと同じtask fixture、tool access、answer contract、usage accountingで比較する。accuracyだけでなくcost、latency、retry、human timeも記録する。
Evidence and provenance
- Anthropic, Building Effective AI Agents — workflow/agent patternと単純構成から複雑性を追加するengineering guidance。author-maintained guidance。
- OpenAI, A practical guide to building agents — workflow、tool、orchestration、tool safeguards、human interventionのengineering/business guidance。product examplesは
PRODUCT_VOLATILE。 - Microsoft Copilot Studio, Agent flows overview — trigger/action、human-in-the-loop、connector、version/deploymentのcurrent implementation example。
PRODUCT_VOLATILE。 - Microsoft Copilot Studio, Multistage and AI approvals in agent flows — manual/AI/conditional approvalのpreview implementation example。preview /
PRODUCT_VOLATILE。 - GitHub, Risks and mitigations for Copilot cloud agent — draft PR、review/merge、workflow approval等のauthority boundary example。
PRODUCT_VOLATILE。 - Microsoft Graph v1.0, List transcripts — meeting transcript取得のpermission/application-access-policy/expiry gate example。
PRODUCT_VOLATILE。 - NIST AI 600-1 — context-specific risk management profileのgovernance evidence。
- AWS Builders' Library, Making retries safe with idempotent APIs — side effectを伴うretry、idempotency、reconciliation設計のengineering evidence。
- Fu et al., Do More Agents Help? — single-agentとmulti-agentをprotocol-alignedに比較したcounterevidence。multi-agent superiorityを前提にしない。
セキュリティとプライバシー
Security: ACTION_CLASSとPERMISSION_SCOPEを必須化し、least privilegeを基本とする。write/executeはreadと別gateにする。
Privacy: meeting/mail/document等のsourceごとに取得権限、retention、sensitive-data handlingを記録する。
Audit: trigger、input/source locator、model/runtime、tool call、approval、artifact revision、final action/resultを追跡可能にする。
Cost: classification/retrieval等を小型model、難判断を上位modelへrouteする選択肢は持てるが、本EAでは価格最適化を再研究しない。cost/routingはEA-018等の別packetへ接続する。
Operability: fixed workflow→single agent→multi-agentの順に複雑性を追加し、各段階をevalで正当化する。stop/escalate/retry/reconcileをpattern契約へ含める。
利用できる条件
共通: provider/plan、organization admin、connector/API availability、identity、permission scope、region、network、data classification、source retention。
会議: transcript生成可否、meeting type、API permission、application access policy、meeting expiry。
メール: mailbox identity、send permission、recipient policy、DLP/attachment rules。
表処理: file access、編集権限、range/schema、formula/protected range。
データ移植: source/target write permission、API quota、transaction/idempotency mechanism、maintenance window。
コード保守: repository access、agent enablement、branch/ruleset、CI secrets/workflow approval、review/merge authority。
確認・評価方法
共通の単一scoreへ統合しない。patternごとに最低1つのdeterministic/observable acceptance criterionを持つ。
- 調査: citation support、source coverage、freshness、unsupported claim率
- 編纂: required-change coverage、unrequested diff、structure preservation、revision/recovery
- 監査: FP/FN、evidence locator再現性、UNKNOWN適切率
- 会議: speaker/action-item attribution、重要事項recall、permission/retention compliance
- メール: recipient/attachment correctness、draft-to-send approval一致、policy violation率
- 表処理: schema/type/formula preservation、cell/range exactness、row/key integrity
- データ移植: source-target reconciliation、duplicate/missing record、idempotent replay、rollback/recovery
- コード保守: tests/static checks、scope diff、regression、PR review findings、merge gate遵守
よくある失敗・反証
製品のagent/flow機能をそのまま業務patternにしない。
「複雑な業務=agent」「さらに複雑=multi-agent」と固定しない。
read-onlyに見える業務でもpermission、admin policy、retention/expiryに依存し得る。
retryはWRITE/EXECUTEで重複副作用を起こし得る。idempotency/reconciliationのない自動再試行を安全とみなさない。
benchmark/task successは実運用のcompliance/permission/auditを保証しない。
provider/tenant availability、plan/region matrixは
PRODUCT_VOLATILE / UNKNOWN。会議録の法的同意要件、メール送信の業界別承認、HR/financial等の高度規制業務はorganization/industry-specificであり、本packetから推測しない。
表処理の共通benchmark、業務横断universal task-success scoreは
OPEN_UNKNOWN。live tenant validation、定量thresholdは未実施・未確定。
実務での使い方
Security: ACTION_CLASSとPERMISSION_SCOPEを必須化し、least privilegeを基本とする。write/executeはreadと別gateにする。
Privacy: meeting/mail/document等のsourceごとに取得権限、retention、sensitive-data handlingを記録する。
Audit: trigger、input/source locator、model/runtime、tool call、approval、artifact revision、final action/resultを追跡可能にする。
Cost: classification/retrieval等を小型model、難判断を上位modelへrouteする選択肢は持てるが、本EAでは価格最適化を再研究しない。cost/routingはEA-018等の別packetへ接続する。
Operability: fixed workflow→single agent→multi-agentの順に複雑性を追加し、各段階をevalで正当化する。stop/escalate/retry/reconcileをpattern契約へ含める。
共通: provider/plan、organization admin、connector/API availability、identity、permission scope、region、network、data classification、source retention。
会議: transcript生成可否、meeting type、API permission、application access policy、meeting expiry。
メール: mailbox identity、send permission、recipient policy、DLP/attachment rules。
表処理: file access、編集権限、range/schema、formula/protected range。
データ移植: source/target write permission、API quota、transaction/idempotency mechanism、maintenance window。
コード保守: repository access、agent enablement、branch/ruleset、CI secrets/workflow approval、review/merge authority。
まだ確認できていないこと
- EA-019-UNKNOWN-01
- 製品のagent/flow機能をそのまま業務patternにしない。
- 「複雑な業務=agent」「さらに複雑=multi-agent」と固定しない。
- read-onlyに見える業務でもpermission、admin policy、retention/expiryに依存し得る。
- retryはWRITE/EXECUTEで重複副作用を起こし得る。idempotency/reconciliationのない自動再試行を安全とみなさない。
- benchmark/task successは実運用のcompliance/permission/auditを保証しない。
- provider/tenant availability、plan/region matrixは
PRODUCT_VOLATILE / UNKNOWN。 - 会議録の法的同意要件、メール送信の業界別承認、HR/financial等の高度規制業務はorganization/industry-specificであり、本packetから推測しない。
- 表処理の共通benchmark、業務横断universal task-success scoreは
OPEN_UNKNOWN。 - live tenant validation、定量thresholdは未実施・未確定。
- EA-019-UNKNOWN-CURRENTNESS
外部根拠の再確認日がcanonical body/control-planeで確定していないため、currentnessはUNKNOWNとして保持する。日付を推測補完しない。
根拠資料
この記事には、直接開ける外部出典が登録されていません。出典IDや検証情報は末尾で確認できます。
出典ID・検証情報・機械可読データ
根拠の種類と情報の鮮度は、ラベルとアイコンで確認できます。
- 記事ID
- EA-019
- 最終確認日
- —
- 提供元・モデル・プラン・利用環境
- —
- 対象地域
- —
元資料の全文と収録照合記録
Public claim
AI業務パターンは、特定製品の機能名やプロンプト例ではなく、「何を正本として、どの入力から、どの権限で、どこまでAIに任せ、誰が承認し、何をもって完了とするか」を再利用可能な型として記述する。
調査、編纂、監査、会議要約、メール、表処理、データ移植、コード保守では必要な制御が異なる。自律化の深さは業務名ではなく、外部作用、可逆性、権限、評価可能性に応じて決める。複雑だからといってmulti-agentが常に有利とは限らない。
Pattern schema
以下のschemaは PROPOSAL であり、provider仕様の必須schemaではない。
- PATTERN_ID / BUSINESS_INTENT
- TRIGGER / INPUT_ARTIFACT
- AUTHORITATIVE_SOURCE
- AI_ROLE
- ACTION_CLASS = READ / DRAFT / WRITE / EXECUTE
- REVERSIBILITY = reversible / compensatable / irreversible
- STATE / CHECKPOINT
- TOOLS / CONNECTORS
- PERMISSION_SCOPE / IDENTITY
- HUMAN_GATE / DECISION_AUTHORITY
- OUTPUT_ARTIFACT / DESTINATION
- EVAL / ACCEPTANCE_CRITERIA
- AUDIT / PROVENANCE
- FAILURE_MODE / RETRY / RECOVERY
- COST / LATENCY / MODEL_ROUTING
- IMPLEMENTATION_TOPOLOGY
Core patternはprovider非依存とし、provider mappingとorganization overlayを別層にする。製品名、model名、preview feature、plan/region availabilityは PRODUCT_VOLATILE として扱う。
Initial pattern cards
A. 調査
ACTION_CLASS: READ中心。 複数sourceからevidence/provenanceを保持してsynthesisする。主なfailureは引用不一致、freshness不足、source権限誤認、unsupported inference。acceptanceはcitation support、coverage、freshness、unsupported claim率で確認する。
B. 編纂
ACTION_CLASS: READ + DRAFT/WRITE。 正本と変更対象を分離し、diff/version/revision、構造保持、rollbackを持つ。acceptanceはrequired-change coverage、unrequested diff、structure preservation、revision/recoveryで確認する。
C. 監査
producerとcriteriaを分離し、evidence locator付きでPASS/FAIL/UNKNOWNを残す。AI自己評価だけでcloseしない。acceptanceはlabeled fixtureに対するFP/FN、evidence locator再現性、UNKNOWN適切率を用いる。
D. 会議
transcript/audioからsummary/action itemsを生成する。取得前にpermission、consent、retention、meeting expiry等のgateを確認する。read-onlyに見える処理でもidentity/permission/retention条件を省略しない。
E. メール
DRAFTとSENDを別patternにする。SENDは外部作用であり、宛先、本文、添付、機密性、最終承認を別gateにする。AIへ閲覧可能であることと外部送信可能であることを同一視しない。
F. 表処理
schema/range/formula/typeを明示し、自然言語の「表を直す」を無境界writeへ変換しない。cell/range validation、formula preservation、row count、key integrity等のdeterministic checkをAI自己評価より優先する。
G. データ移植
ACTION_CLASS: WRITE/EXECUTE。 source→target mapping、idempotency、checkpoint、retry、duplicate detection、reconciliation、dry-run/rollbackを持つ。件数一致だけを成功条件にせず、retryによる重複side effectをfailure envelopeへ含める。
H. コード保守
repository scope→plan/branch→change→tests→diff→PR→review→mergeを分離する。変更生成能力とmerge authorityを同一視しない。branch/ruleset、CI、secrets、Actions approval、review/merge authorityをgateとして扱う。
Implementation topology
workflow / agent / multi-agentは業務patternそのものではなく実装方式として分離する。
固定分解可能な仕事にはprompt chaining、入力分類が明瞭ならrouting、独立subtaskならparallelization、動的分解が必要ならorchestrator-worker、明確な評価基準がある反復改善ならevaluator-optimizer等を候補にできる。ただしこれはpatternから一意に決めず、実測evalで正当化する。
multi-agent採用時はsingle-agentまたはfixed-workflow baselineと同じtask fixture、tool access、answer contract、usage accountingで比較する。accuracyだけでなくcost、latency、retry、human timeも記録する。
Evidence and provenance
- Anthropic, Building Effective AI Agents — workflow/agent patternと単純構成から複雑性を追加するengineering guidance。author-maintained guidance。
- OpenAI, A practical guide to building agents — workflow、tool、orchestration、tool safeguards、human interventionのengineering/business guidance。product examplesは
PRODUCT_VOLATILE。 - Microsoft Copilot Studio, Agent flows overview — trigger/action、human-in-the-loop、connector、version/deploymentのcurrent implementation example。
PRODUCT_VOLATILE。 - Microsoft Copilot Studio, Multistage and AI approvals in agent flows — manual/AI/conditional approvalのpreview implementation example。preview /
PRODUCT_VOLATILE。 - GitHub, Risks and mitigations for Copilot cloud agent — draft PR、review/merge、workflow approval等のauthority boundary example。
PRODUCT_VOLATILE。 - Microsoft Graph v1.0, List transcripts — meeting transcript取得のpermission/application-access-policy/expiry gate example。
PRODUCT_VOLATILE。 - NIST AI 600-1 — context-specific risk management profileのgovernance evidence。
- AWS Builders' Library, Making retries safe with idempotent APIs — side effectを伴うretry、idempotency、reconciliation設計のengineering evidence。
- Fu et al., Do More Agents Help? — single-agentとmulti-agentをprotocol-alignedに比較したcounterevidence。multi-agent superiorityを前提にしない。
Security / privacy / audit / cost / operability
Security: ACTION_CLASSとPERMISSION_SCOPEを必須化し、least privilegeを基本とする。write/executeはreadと別gateにする。
Privacy: meeting/mail/document等のsourceごとに取得権限、retention、sensitive-data handlingを記録する。
Audit: trigger、input/source locator、model/runtime、tool call、approval、artifact revision、final action/resultを追跡可能にする。
Cost: classification/retrieval等を小型model、難判断を上位modelへrouteする選択肢は持てるが、本EAでは価格最適化を再研究しない。cost/routingはEA-018等の別packetへ接続する。
Operability: fixed workflow→single agent→multi-agentの順に複雑性を追加し、各段階をevalで正当化する。stop/escalate/retry/reconcileをpattern契約へ含める。
Availability gates
共通: provider/plan、organization admin、connector/API availability、identity、permission scope、region、network、data classification、source retention。
会議: transcript生成可否、meeting type、API permission、application access policy、meeting expiry。
メール: mailbox identity、send permission、recipient policy、DLP/attachment rules。
表処理: file access、編集権限、range/schema、formula/protected range。
データ移植: source/target write permission、API quota、transaction/idempotency mechanism、maintenance window。
コード保守: repository access、agent enablement、branch/ruleset、CI secrets/workflow approval、review/merge authority。
Evaluation
共通の単一scoreへ統合しない。patternごとに最低1つのdeterministic/observable acceptance criterionを持つ。
- 調査: citation support、source coverage、freshness、unsupported claim率
- 編纂: required-change coverage、unrequested diff、structure preservation、revision/recovery
- 監査: FP/FN、evidence locator再現性、UNKNOWN適切率
- 会議: speaker/action-item attribution、重要事項recall、permission/retention compliance
- メール: recipient/attachment correctness、draft-to-send approval一致、policy violation率
- 表処理: schema/type/formula preservation、cell/range exactness、row/key integrity
- データ移植: source-target reconciliation、duplicate/missing record、idempotent replay、rollback/recovery
- コード保守: tests/static checks、scope diff、regression、PR review findings、merge gate遵守
Failure envelope / OPEN_UNKNOWN
- 製品のagent/flow機能をそのまま業務patternにしない。
- 「複雑な業務=agent」「さらに複雑=multi-agent」と固定しない。
- read-onlyに見える業務でもpermission、admin policy、retention/expiryに依存し得る。
- retryはWRITE/EXECUTEで重複副作用を起こし得る。idempotency/reconciliationのない自動再試行を安全とみなさない。
- benchmark/task successは実運用のcompliance/permission/auditを保証しない。
- provider/tenant availability、plan/region matrixは
PRODUCT_VOLATILE / UNKNOWN。 - 会議録の法的同意要件、メール送信の業界別承認、HR/financial等の高度規制業務はorganization/industry-specificであり、本packetから推測しない。
- 表処理の共通benchmark、業務横断universal task-success scoreは
OPEN_UNKNOWN。 - live tenant validation、定量thresholdは未実施・未確定。
EA-019-R11-RESEARCH研究資料研究資料根拠の出所: AUDITED_CANONICAL_RESEARCH_PACKETEA-019 監査済みresearch / canonical revision binding
- 裏付ける内容
- AI業務パターンは、特定製品の機能名やプロンプト例ではなく、「何を正本として、どの入力から、どの権限で、どこまでAIに任せ、誰が承認し、何をもって完了とするか」を再利用可能な型として記述する。
- 確認日
- —
- 出典・実験ID
- COMM-020-EA0019
- 検証箇所
- COMM-020-EA0019 · EA-019-R5-LEGACY-MIGRATION-20261008-R1 · content/staging/EA-019.md
- 適用範囲
- 監査済みEA本文・canonical revision・既存Source Graph relationの範囲。欠損currentnessは推測で閉じない。
- 出典・来歴
- AUDIT_PASS_CANONICAL_BINDING
- 限界
- canonical監査・revision bindingの存在を示す。外部ソースcurrentnessが本文またはcontrol-planeで確定していない場合は、currentnessをUNKNOWNのまま保持する。
EA-019-R11-WEB-READBACK実装資料実装資料根拠の出所: IMPLEMENTATION_READBACKEA-019 Web body identity / canonical readback
- 裏付ける内容
- canonical staging bodyのSHA-256一致とR9 canonical ledger readbackをProduction projectionの入力として検証する。
- 確認日
- —
- 出典・実験ID
- WEBBODY-EA0019-R8-7ABF6DCE
- 検証箇所
- WEBBODY-EA0019-R8-7ABF6DCE · content/staging/EA-019.md · EA-019-R5-LEGACY-MIGRATION-20261008-R1
- 適用範囲
- R9/R10 canonical readback後のProduction生成時body identity。
- 出典・来歴
- CANONICAL_READBACK_BODY_HASH_MATCH
- 限界
- body identity/readbackは本文claim自体の真偽や外部ソースの最新性を追加保証しない。
- 出典ID
- COMM-020-EA0019, WEBBODY-EA0019-R8-7ABF6DCE
- 追跡中のUNKNOWN ID
- EA-019-UNKNOWN-01, EA-019-UNKNOWN-CURRENTNESS
- 再確認のきっかけ
- canonical revision/publication state change · body artifact hash change · source currentness change · new contradiction or implementation readback
機械検査: 通過 — Automated validation does not guarantee accuracy or authorize execution.
同じ記事IDの機械可読データです。