カテゴリー: IT

週刊 AI Governance Watch｜2026年6月8日調査版

by 塚井海地

前回記事（2026年6月1日公開）から見えてきた「Agent Assurance」時代への移行

前回記事：
https://kaichitsukai.com/2026/06/01/%e9%80%b1%e5%88%8a-ai-governance-watch/

本記事で得られる3つのポイント

  • AI Governanceの中心テーマが「Trustworthy AI」から「Agent Governance」「Agent Assurance」へ移行し始めている
  • OWASP・NIST・ISO42001が単独フレームワークではなく、「AI統制基盤」として統合的に扱われ始めている
  • AI Agentの継続監視（Continuous Monitoring）が実装フェーズへ入りつつある

なぜ重要か

前回記事では「AIをどう統治するか」が中心テーマでした。しかし今週確認できた更新情報からは、「AI Agentをどう継続監視し続けるか」が次の主戦場になりつつあることが見えてきました。

Agent Governanceから「Agent Assurance」へ

今週、企業実装領域で特に注目されたのは、AI Agentそのものを継続的に監査・評価・監視する動きです。

米Workdayは「Agent Passport」を発表しました。

参照URL：
https://www.prnewswire.com/news-releases/workday-launches-agent-passport-to-test-verify-and-continuously-monitor-every-ai-agent-in-the-enterprise-302787979.html

同発表では、

  • OWASP LLM Top 10
  • NIST AI RMF
  • MITRE ATLAS

などをベースに、AI Agentを継続監視すると説明されています。

これは単なるAI Security強化ではありません。

これまでのAI Governanceは、

  • モデル管理
  • リスク管理
  • ポリシー整備

が中心でした。

しかし現在は、

「AI Agentが実行中に何をしたか」

まで監査対象になり始めています。

これは非常に重要な変化です。

EU AI Actは「規制」から「監査」へ移行し始めている

EU AI Actは引き続き2026年8月2日の本格適用へ向けて進行しています。

参照URL：
https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai

今週確認できた情報では、特にGPAI（General Purpose AI）向け運用体制の具体化が進んでいます。

参照URL：
https://digital-strategy.ec.europa.eu/en/policies/contents-code-gpai

前回記事でも触れたGPAI Code of Practiceですが、今回確認できた動向では、

  • モデル提供企業
  • モデル利用企業
  • 統合サービス提供企業

それぞれに説明責任が求められる方向性がさらに明確になっています。

現時点で確認できる範囲では、EU AI Actは単なる「禁止・規制法」ではなく、

「AI監査法」

に近づき始めているように見えます。

特に今後は、

  • モデル評価
  • Runtime Monitoring
  • Audit Logging
  • Human Oversight

が実務上の主要論点になる可能性があります。

OECD・UNESCOは「Trustworthy AI」を維持

Trustworthy AIという言葉自体が消えたわけではありません。

OECD AI Principlesでは引き続き、

  • Human Rights
  • Transparency
  • Accountability
  • Democratic Values

が中核概念として維持されています。

参照URL：
https://www.oecd.org/en/topics/sub-issues/ai-principles.html

参照URL：
https://legalinstruments.oecd.org/en/instruments/oecd-legal-0449

またUNESCOも、

「Recommendation on the Ethics of Artificial Intelligence」

を継続しています。

参照URL：
https://www.unesco.org/en/artificial-intelligence/recommendation-ethics

ただし実務の世界では、Trustworthy AI単体で語られるケースは減少しつつあります。

現在の構造を整理すると、

Trustworthy AI
↓
Responsible AI
↓
AI Governance
↓
AI Security
↓
Agent Governance
↓
Agent Assurance

という多層構造になり始めていると考えられます。

NIST AI RMFは「Agent Runtime Risk」へ拡張し始めた

NIST AI RMFは引き続き、事実上のグローバル標準フレームワークとして扱われています。

参照URL：
https://www.nist.gov/itl/ai-risk-management-framework

今週特に注目されたのは、Agentic AI向けプロファイル整備です。

関連資料：
https://labs.cloudsecurityalliance.org/agentic/agentic-nist-ai-rmf-profile-v1/

ここで議論されているのは、単なるモデルリスクではありません。

現在対象になり始めているのは、

  • Tool権限制御
  • Runtime Behavior
  • Agent Interoperability
  • Autonomous Execution
  • Runtime Oversight

です。

つまりNIST AI RMFも、

「モデル管理」

から、

「Agent実行環境管理」

へ対象範囲を広げ始めています。

OWASP LLM Top 10は「防御評価基準」へ進化

OWASP LLM Top 10は依然として企業実装の中心基準です。

参照URL：
https://owasp.org/www-project-top-10-for-large-language-model-applications/

しかし今週確認できた研究では、OWASP LLM Top 10を「脅威一覧」としてではなく、

「防御評価基準」

として扱う流れが見え始めています。

参照URL：
https://arxiv.org/abs/2606.02822

研究では、

  • Prompt Injection
  • Jailbreak
  • Tool Abuse
  • Prompt Leakage

への防御有効性が分析されています。

これはAI Security分野が、

「脆弱性列挙」

から、

「Runtime Defense」

へ進化していることを示しているように見えます。

ISO/IEC 42001は「AI統治基盤」へ

ISO/IEC 42001も引き続き存在感を強めています。

参照URL：
https://www.iso.org/standard/81230.html

以前は、

「AI版ISO27001」

という説明が多く見られました。

しかし最近の実装動向を見る限り、より実態に近い表現は、

「AI統治の共通管理基盤」

です。

現在対象になっているのは、

  • AI Lifecycle
  • Supplier Governance
  • Risk Assessment
  • Monitoring
  • Human Oversight

まで広がっています。

つまりISO42001は、

AI Governance全体を統合管理する枠組み

へ進化しつつあります。

企業実装で共通して見えてきた変化

主要企業を確認すると、方向性はかなり共通しています。

Palantir

引き続き、

  • Ontology
  • Permission Layer
  • Auditability

が強みです。

AI Governance実装企業としては依然として先行しています。

OpenAI

参照URL：
https://openai.com/

Enterprise市場では、

  • Evaluation
  • Governance
  • Agent

への重点移行が続いています。

Anthropic

Constitutional AIとResponsible Scaling Policyを継続。

依然として「安全性」を前面に出しています。

Google

Gemini企業導入拡大に伴い、

  • Governance
  • Compliance
  • Data Controls

が重要性を増しています。

Microsoft

Copilot展開拡大に伴い、

  • Agent Governance
  • Runtime Control
  • Compliance

需要が急増しています。

IBM

watsonx Governanceを中心に、

AI Governance Platform企業としての立ち位置を強化しています。

OneTrust

Privacy Governance企業から、

AI Governance Platform企業への転換が進行しています。

今週の考察

前回記事では、

「AIをどう統治するか」

が中心テーマでした。

しかし今週確認できた動向からは、

「AI Agentをどう監視し続けるか」

へ論点が移行し始めているように見えます。

これは単なる技術論ではありません。

企業が実際にAI Agentを本番環境へ投入し始めた結果、

  • Runtime Risk
  • Continuous Monitoring
  • Human Oversight
  • Auditability

が現実問題になり始めています。

現時点で確認できる範囲では、

2026年後半から2027年にかけて、

「Agent Assurance」

がAI Governance領域の最重要キーワードになる可能性があります。

次回追跡ポイント

  • EU GPAI Code of Practice最終動向
  • NIST Agentic AI Profile
  • OWASP Agent Security
  • ISO42001認証事例
  • OECD AI Observatory更新
  • UNESCO AI Ethics更新
  • OpenAI Enterprise Governance機能
  • Anthropic Safety Framework
  • Palantir AIP更新
  • Runtime Monitoring製品群

参照URL

https://oecd.ai

https://www.oecd.org/en/topics/sub-issues/ai-principles.html

https://legalinstruments.oecd.org/en/instruments/oecd-legal-0449

https://www.unesco.org/en/artificial-intelligence/recommendation-ethics

https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai

https://digital-strategy.ec.europa.eu/en/policies/contents-code-gpai

https://www.nist.gov/itl/ai-risk-management-framework

https://owasp.org/www-project-top-10-for-large-language-model-applications

https://www.iso.org/standard/81230.html

NIST AI Risk Management Framework: Agentic Profile

https://www.prnewswire.com/news-releases/workday-launches-agent-passport-to-test-verify-and-continuously-monitor-every-ai-agent-in-the-enterprise-302787979.html

https://arxiv.org/abs/2606.02822

週次FDE Watch 2026年6月8日調査：FDEは職種名からAI実装モデルへ広がり始めた

by 塚井海地

週次FDE Watch：2026年6月8日調査レポート

本記事で得られる3つのポイント

  • 2026年6月1日の前回調査以降、FDEという職種名そのものだけでなく、AI Deployment Engineer、Applied AI Engineer、AI Builder、AI Orchestratorなど、FDEに近い実装人材モデルが各社で広がっていることが確認できる。
  • OpenAI、Anthropic、Salesforce、EY、KPMG、Microsoft、Google Cloud、AWSなどの公開情報を見ると、AI導入の主戦場はPoCから本番業務への実装・定着・改善へ移っていると考えられる。
  • 日本企業にとって重要なのは、FDEという肩書きを輸入することではなく、暗黙知、社内IT、SES、業務部門、HRを含めて、AI導入の実装責任を誰が持つかを明確にすることである。

なぜ重要か：
AI導入の成否は、モデル性能やツール選定だけでなく、業務現場に入り込み、データ・権限・業務フロー・評価・運用まで接続できる実装人材に左右され始めているためです。

調査日と前回記事との位置づけ

本記事は、2026年6月8日時点で実施したFDE／AI実装人材に関する週次調査レポートです。

前回調査記事はこちらです。

週次FDE Watch：FDEは「AI導入職」から「業務変革の実装責任者」へ
https://kaichitsukai.com/2026/06/01/%e9%80%b1%e6%ac%a1fde-watch%ef%bc%9afde%e3%81%af%e3%80%8cai%e5%b0%8e%e5%85%a5%e8%81%b7%e3%80%8d%e3%81%8b%e3%82%89%e3%80%8c%e6%a5%ad%e5%8b%99%e5%a4%89%e9%9d%a9%e3%81%ae%e5%ae%9f%e8%a3%85%e8%b2%ac/

前回の2026年6月1日調査では、FDE、Forward Deployed Engineer、Forward Deployed Software Engineer、FDSEという職種が、Palantir由来の特殊な働き方から、OpenAI、Anthropic、Salesforce、EY、Microsoft、Google Cloud、AWS、日本企業へ広がりつつある点を整理しました。

今回の2026年6月8日調査では、前回記事と同じ説明を繰り返すのではなく、以下の3点に絞って再確認します。

  • 前回調査後に追加で確認すべき公開情報
  • 既存情報の意味合いの変化
  • 日本企業が実務上どのように受け止めるべきか

結論から言えば、今回の焦点は「FDEという職種名が増えたかどうか」ではありません。

むしろ重要なのは、各社が異なる名称を使いながらも、AIを本番業務へ接続するための人材・組織・サービスモデルを整え始めている点です。

2026年6月8日調査の結論

今回の調査で最も重要だと考えられるのは、FDEが単なる職種名から、AI実装モデルへ広がり始めている点です。

前回記事の段階では、FDEはまだ「Palantir型の職種が、OpenAIやAnthropicにも広がっている」という見方が中心でした。

しかし、2026年6月8日時点で公開情報を横断すると、より正確には次のように見るのが妥当です。

FDEは、単独の肩書きとして広がっているだけではありません。
企業ごとに異なる名称へ分化しながら、実態としては「AIを業務現場へ実装する役割」として再構成されています。

たとえば、OpenAIはDeployment CompanyやAI Deployment Engineerという言葉を使っています。AnthropicはApplied AIの文脈でForward Deployed EngineerやApplied AI Engineerを採用しています。SalesforceはAgentforce導入の文脈でFDEを説明しています。EYはForward Deployed Engineerという名称を明確に使い、KPMGはAI Buildersとして近い役割を定義しています。MicrosoftはAgent Factory、Google CloudはGemini Enterprise Agent Platform、AWSはForward Deployed AI IntegratorやGenAI Innovation Center関連職を通じて、企業AIの実装支援を強めています。

名称は揃っていません。
しかし、向かっている先は近いと考えられます。

共通しているのは、AIモデルやAIエージェントを、企業の業務フロー、データ、権限、監査、評価、運用改善へ接続することです。

つまり、FDEは「AIに詳しいエンジニア」というだけでは不十分です。
現場業務を理解し、業務課題を構造化し、AIを本番運用に耐える形へ落とし込む実装責任者として捉えるべき段階に入っています。

今週の更新有無：2026年6月8日調査

海外主要ソース

組織・情報源2026年6月8日時点の確認結果内容
Palantir Blog継続確認AIエージェントを意思決定へ接続する文脈を継続確認
Palantir Foundry / AIP Docs継続確認Ontology MCP、AIP Analyst、AIP token usage exportなど、本番運用基盤の流れを再確認
OpenAI News重要シグナル継続OpenAI Deployment Companyが、FDE的な実装組織化の中心論点
OpenAI Careers追加確認AI Deployment Engineer、Partner AI Deployment Engineer、FDE関連求人を確認
Anthropic Careers / Applied AI追加確認Forward Deployed Engineer, Applied AI、Applied AI Engineer、Applied AI Architectを確認
Accenture Newsroom継続確認Palantir連携、AI reinvention、agentic AI実装支援の流れを確認
Salesforce Blog / News追加確認Agentforce文脈でFDEを説明する公式ブログを確認
Salesforce Careers一部不明FDE求人は確認対象だが、2026年6月8日時点で安定的に取得できる一次情報は限定的
ServiceNow Autonomous Workforce継続確認FDEという名称ではなく、AI Orchestrator / Autonomous Workforceとして近い機能を確認
Box Blog追加確認Box Automate、AI-first workflow、agentic workflowsの連続発信を確認
Deloitte不明FDE相当職の明確な一次情報は限定的。Agentic AIや仕事再設計の文脈として扱うのが妥当
EY Newsroom / Careers重要更新継続FDE roles、Applied AI付きFDE求人を確認
PwC Insights / Careers追加確認Agentic AI、AI/ML Developer系職種を確認
KPMG Insights / Careers追加確認AI orchestration、AI Builders職を確認
Microsoft News / Agent Factory追加確認Agent FactoryとForward Deployed Engineering支援の記述を確認
Google Cloud Blog / Japan Blog継続確認Gemini Enterprise Agent Platform、Agentic Enterprise文脈を確認
AWS Blog / APN / Marketplace / Amazon Jobs追加確認Forward Deployed AI Integrator、agentic AI categories、MarketplaceでのAI agent関連サービスを確認
ReceiptRoller FDE series追加確認FDE連載の更新を確認
Pragmatic Engineer不明2026年6月8日時点で安定的な新規一次確認は限定的
SVPG更新なし既存のFDE記事が引き続き参照対象
Pave不明2026年6月8日時点で安定的な新規確認は限定的
IT Brew不明2026年6月8日時点で安定的な新規確認は限定的
MarketWatch継続確認OpenAI / AnthropicがPalantir型に近づいているという市場解釈を確認

日本国内ソース

組織・情報源2026年6月8日時点の確認結果内容
LayerX FDE / Ai Workforce継続確認FDE採用、FDEインターン、Ai Workforce事業文脈を確認
Loglass FDE継続確認AI経営実装、FDE、AIソリューションエンジニアの求人を確認
JDSC FDE不明FDEを明示する一次情報は限定的
SB OAI Japan継続確認OpenAI Frontier基盤、Crystal intelligence展開文脈を確認
Salesforce Japan不明国内向けにFDEを強く打ち出す一次更新は限定的
国内コンサル / SIer不明生成AI導入支援は多数あるが、FDEとの差分説明は限定的
日本のDX / 暗黙知 / SES / 社内IT / HR重要論点FDE導入時の実務課題として継続観測が必要

追加確認した主な事実

OpenAI：Deployment CompanyはFDE的組織化の象徴

OpenAIのDeployment Companyは、前回記事でも重要なシグナルとして扱いました。2026年6月8日調査であらためて注目すべき点は、これが単なる導入支援ではなく、企業の業務変革を実装する組織能力として位置づけられている点です。

OpenAIは、AI Deployment EngineerやPartner AI Deployment Engineerなど、顧客現場でAIを本番導入する職種を複数掲出しています。ここからは、OpenAIがモデル提供だけでなく、顧客企業の業務に入り込み、AI活用を実装する体制を整えようとしていることが読み取れます。

参照URL：
https://openai.com/index/openai-launches-the-deployment-company/
https://openai.com/careers/ai-deployment-engineer-seoul-south-korea/
https://openai.com/careers/partner-ai-deployment-engineer-san-francisco/
https://openai.com/careers/search/?q=deployment
https://openai.com/careers/forward-deployed-engineer-%28fde%29-nyc-new-york-city/

前回調査との差分としては、OpenAIを「FDEを採り始めた企業」と見るより、AIモデル企業が「デプロイメント能力」を事業の中核に置き始めた、と捉える方が正確です。

Anthropic：Applied AIはFDEの別表現に近い

Anthropicでは、Forward Deployed Engineer, Applied AIのほか、Applied AI Engineer、Applied AI Architectなどの職種が確認できます。

重要なのは、AnthropicがFDEという言葉を使っているかどうかだけではありません。Applied AIという領域そのものが、顧客企業の業務にAIを適用し、実装し、価値に変える職能を意味している点です。

参照URL：
https://www.anthropic.com/careers/jobs
https://www.anthropic.com/careers/jobs/5057647008
https://www.anthropic.com/careers/jobs/5057258008

2026年6月8日時点では、FDEという名前の求人だけを追っていても、実態を見落とす可能性があります。
Applied AI、AI Deployment、AI Architect、AI Transformation、AI Builderといった周辺職種まで含めて見る必要があります。

Salesforce：Agentforce導入にFDEが接続される

Salesforceは、Agentforce文脈でFDEを公式ブログ上でも取り上げています。AgentforceはAIエージェントを業務に組み込むための製品群ですが、製品だけで業務変革が完了するわけではありません。

顧客ごとの業務プロセス、CRMデータ、営業・サポート・バックオフィスの実務にAIエージェントを接続する役割が必要になります。SalesforceがFDEを語る意味は、ここにあります。

参照URL：
https://www.salesforce.com/ap/blog/forward-deployed-engineer/
https://www.salesforce.com/ap/blog/author/andrew-luther/
https://www.salesforce.com/ap/blog/category/agentforce/

前回調査では、SalesforceのFDEを「Agentforce導入職」として整理しました。2026年6月8日時点では、より広く「SaaS企業がAIエージェント導入のためにFDE的な実装部隊を必要とし始めている」と見るのが妥当です。

Palantir：OntologyはFDEの作業対象そのもの

Palantirについては、前回記事と重なるため、ここでは要点に絞ります。

PalantirのOntologyやAIPは、FDEが現場で扱うべき対象を非常に分かりやすく示しています。AIを業務に入れるには、データだけでは足りません。業務上の対象物、権限、アクション、判断、監査、例外処理を構造化する必要があります。

参照URL：
https://palantir.com/docs/foundry/announcements/2026-01/
https://palantir.com/docs/foundry/announcements/2026-03/
https://palantir.com/docs/foundry/announcements/2026-05/
https://blog.palantir.com/connecting-agents-to-decisions-277dee8ddb40
https://palantir.com/docs/foundry/platform-overview/overview/

Palantirを単なる一企業として見るだけではなく、FDEという職種がなぜ必要になるのかを理解するための参照モデルとして見ることが重要です。

AI導入とは、チャット画面を増やすことではありません。
業務の構造をAIが扱える形にすることです。

EY・KPMG・PwC：Big4も実装職へ寄り始めている

前回調査では、EY、PwC、KPMG、Deloitteをまとめて扱いました。2026年6月8日調査では、EYとKPMGの動きが特に分かりやすいと考えられます。

EYは、Forward Deployed Engineer AI rolesを打ち出し、Applied AI付きのFDE求人を掲出しています。これは、コンサルティング会社が戦略提案だけでなく、AI実装そのものに踏み込もうとしているシグナルと見られます。

参照URL：
https://www.ey.com/en_uk/newsroom/2026/04/ey-launches-fde-roles
https://careers.ey.com/ey/job/New-York-Forward-Deployed-Engineer-Applied-AI-Manager-Financial-Services-Consulting-NY-10001-8604/1393514533/
https://careers.ey.com/ey/job/New-York-Forward-Deployed-Engineer-Applied-AI-Senior-Financial-Services-Consulting-NY-10001-8604/1393540633/
https://careers.ey.com/ey/job/New-York-Forward-Deployed-Engineer-Applied-AI-Senior-Manager-Financial-Services-Consulting-NY-10001-8604/1393575733/

KPMGはAI Buildersという形で、プロトタイプから本番、さらにポストデプロイまでを含む職種を確認できます。

参照URL：
https://kpmg.com/ca/en/careers/experienced-hires/ai.html
https://kpmg.com/ee/en/insights/2026/05/Global-AI-Pulse.html
https://kpmg.com/in/en/insights/2026/04/ai-pulse-q1-2026.html

PwCも、Agentic AI and Machine Learning Developerなど、AIをスケールさせる実装寄りの職種を確認できます。

参照URL：
https://jobs.us.pwc.com/job/new-york/acceleration-center-agentic-ai-and-machine-learning-developer-experienced-associate/932/95591450096
https://jobs.us.pwc.com/job/new-york/acceleration-center-agentic-ai-and-machine-learning-developer-senior-associate/932/95625372864

この流れから考えると、Big4におけるAI支援も、資料作成や構想策定だけでは競争力を維持しにくくなる可能性があります。今後は、実装できるコンサルタント、あるいは業務変革に深く入れるエンジニアの価値が上がると考えられます。

Microsoft・Google Cloud・AWS：クラウド勢はFDEを仕組み化している

Microsoft、Google Cloud、AWSの動きは、FDEそのものというより、FDE的な実装を支える基盤・パートナー網・マーケットプレイスの整備として見るべきです。

MicrosoftはAgent Factoryを打ち出し、AIエージェントを企業内で構築・展開するための考え方を示しています。

参照URL：
https://www.microsoft.com/en/ai/agent-factory
https://www.microsoft.com/ja-jp/ai/agent-factory
https://cdn-dynmedia-1.microsoft.com/is/content/microsoftcorp/microsoft/bade/documents/products-and-services/en-us/ai/The-Microsoft-Agent-Factory-white-paper-Feb-2026.pdf
https://news.microsoft.com/source/2026/05/21/ey-and-microsoft-announce-global-initiative-to-help-clients-scale-ai-enterprisewide-value-creation-and-move-beyond-experimentation/

Google Cloudは、Gemini Enterprise Agent PlatformやAgentic Enterpriseを通じて、AIエージェントの開発・統合・管理・セキュリティを一体化しようとしています。

参照URL：
https://cloud.google.com/blog/products/ai-machine-learning/introducing-gemini-enterprise-agent-platform
https://cloud.google.com/blog/topics/google-cloud-next/welcome-to-google-cloud-next26
https://cloud.google.com/blog/ja/products/ai-machine-learning/introducing-gemini-enterprise-agent-platform
https://cloud.google.com/blog/ja/topics/google-cloud-next/welcome-to-google-cloud-next26

AWSでは、Forward Deployed AI IntegratorやForward Deployed Deep Learning Architectに加え、APNやMarketplaceを通じたagentic AI関連サービスの流通が確認できます。

参照URL：
https://www.amazon.jobs/en/search?base_query=sagemaker&city=&country=&county=&invalid_location=false&latitude=&loc_group_id=&loc_query=&longitude=&region=
https://aws.amazon.com/blogs/apn/new-agentic-ai-categories-for-aws-ai-competency-partners/
https://aws.amazon.com/blogs/apn/tag/ai-agents/
https://aws.amazon.com/blogs/apn/accenture-and-aws-accelerate-data-transformation-with-agentic-ai/
https://aws.amazon.com/blogs/machine-learning/beyond-pilots-a-proven-framework-for-scaling-ai-to-production/

ここで見えるのは、FDEが個人の職人芸だけでは成立しないという点です。

実装人材、クラウド基盤、パートナー企業、マーケットプレイス、評価・監査の仕組みが組み合わさって、初めてAI導入は本番運用に近づきます。

日本企業への実務示唆

暗黙知をAIに渡せる形へ変換する必要がある

日本企業における最大の論点は、暗黙知です。

多くの現場では、判断基準、例外処理、顧客ごとの対応、社内調整、上司への確認タイミングなどが、明文化されていません。いわば「見れば分かる」「やれば分かる」「あの人に聞けば分かる」で回っています。

これ自体は、日本企業の強みでもあります。
しかし、AI実装においては、そのままでは扱いにくい資産になります。

FDE的な役割が必要になるのは、ここです。
現場の暗黙知を、業務フロー、判断条件、データ項目、権限、例外処理、評価指標へ変換する人材が必要になります。

これは、単なるプロンプト作成ではありません。
業務の骨格を組み直す作業です。大工仕事でいえば、壁紙を貼る前に柱と梁を見る作業です。見た目は地味ですが、ここを間違えると家は傾きます。

SESや従来型SIの看板替えにしてはいけない

日本でFDEを導入する際、最も注意すべき点は、従来型のSESやSIの看板替えにしてしまうことです。

FDEという名前を使っても、実態が「顧客先に常駐して、言われたものを作る人」であれば、従来の延長にすぎません。

本来のFDEに近づけるには、少なくとも次の要素が必要です。

観点従来型SES / SIFDE的な実装人材
起点要件定義書業務成果・現場課題
役割開発・設定・保守課題発見・実装・定着・改善
顧客接点PM、営業、上流担当が中心エンジニア自身が現場に深く入る
成果物システム、画面、ドキュメント業務変革、AIワークフロー、再利用可能な知見
成功条件納期、予算、仕様充足業務KPI改善、現場定着、運用改善
最大リスク人月化高級SES化、個別開発の乱立

FDEを名乗るだけなら簡単です。
しかし、それでは横文字の暖簾を掛け替えただけになります。暖簾は立派でも、店の出汁が薄ければ客は戻ってきません。

社内ITは守りから実装オーナーへ役割を広げる必要がある

日本企業では、社内IT部門がAI実装の鍵を握る可能性があります。

理由は単純です。
社内ITは、既存システム、権限、業務アプリケーション、部門間の力学、現場の困りごとを知っています。

一方で、従来の社内ITは、安定運用、問い合わせ対応、障害対応、アカウント管理、ベンダー調整が中心になりがちでした。もちろん、それらは今後も重要です。しかし、AI導入が本格化すると、社内ITには次のような役割が求められます。

  • AIが触れてよいデータと触れてはいけないデータを整理する
  • 業務部門とともにAIエージェントの適用範囲を決める
  • 例外処理や人間承認のポイントを設計する
  • セキュリティ、監査、ログ、権限管理を実装する
  • 導入後の改善サイクルを回す

これは、単なるIT運用ではありません。
AI時代の業務実装オーナーに近い役割です。

HRはAI人材ではなく実装責任者を定義すべき

HR部門にとっての論点も重要です。

今後、「生成AI人材」「AI活用人材」「DX人材」という言葉はさらに増えるでしょう。しかし、それだけでは採用要件として曖昧です。

FDE的な人材を採用・育成するなら、以下の能力を分けて定義する必要があります。

能力内容
業務理解現場業務、例外処理、KPI、部門間調整を理解する力
技術実装API、データ連携、LLM、AIエージェント、クラウドを扱う力
データ設計業務データの品質、構造、権限、監査を設計する力
プロダクト思考個別対応で終わらせず、再利用可能な仕組みに戻す力
チェンジマネジメント現場に使われる状態まで持っていく力
評価設計AI導入の効果を測定し、改善につなげる力

この人材像は、単純なエンジニアでも、従来型コンサルタントでも、一般的な情シス担当でもありません。

複数の能力をまたぐ、ハイブリッド人材です。

そのため、日本企業では外部採用だけでなく、社内IT、業務部門のエース、データ担当、PM経験者を組み合わせた育成も現実的な選択肢になります。

日本でFDEを導入するなら、最初に決めるべきこと

対象業務を絞る

最初から全社AI変革を狙うと、話が大きくなりすぎます。

まずは、成果が測定しやすく、現場の負荷も見えやすい業務に絞るべきです。

候補としては、以下のような業務が考えられます。

  • 社内問い合わせ対応
  • 営業提案資料の下準備
  • 契約書・稟議書の一次レビュー
  • 経営管理レポート作成
  • カスタマーサポートの回答支援
  • ナレッジ検索
  • 請求・経費・購買の例外処理

業務オーナーを明確にする

AI導入でよくある失敗は、情報システム部門やDX部門だけが責任を背負うことです。

AIが業務を変える以上、業務部門側のオーナーが必要です。
誰のKPIを改善するのか。誰が現場の判断基準を提供するのか。誰が導入後の成果を評価するのか。ここを曖昧にすると、AI導入は便利ツール配布で止まります。

FDE的役割をチームで担う

最初から一人で全てをこなすスーパーマンを探す必要はありません。むしろ、日本企業では小さな混成チームとして始める方が現実的です。

役割主な責任
業務オーナーKPI、現場調整、意思決定
AI実装リードAIワークフロー設計、プロトタイプ、本番化
社内IT / セキュリティ担当データ接続、権限、監査、ログ管理
現場キーユーザー暗黙知、例外処理、受入評価
変革PM導入計画、教育、定着、効果測定

このチーム全体が、日本版FDEの初期形になると考えられます。

事実・分析・仮説の整理

事実

2026年6月8日時点の公開情報からは、OpenAI、Anthropic、Salesforce、EYなどで、FDEまたはFDEに近い職種・組織が確認できます。

PalantirはOntologyやAIPを通じて、AIを業務・意思決定・アクションへ接続する基盤を提示しています。

Microsoft、Google Cloud、AWSは、AIエージェントの企業実装を支える基盤、パートナー網、マーケットプレイスを整備しています。

日本でもLayerX、Loglass、SB OAI Japanなど、AIを業務や経営に実装する動きが確認できます。

分析

FDEは、単なる職種名ではなく、AI導入における実装責任の再配置を示す概念になりつつあります。

各社は異なる名称を使っていますが、実態としては「AIを本番業務へ接続する人材・組織」へ収斂していると考えられます。

日本企業では、暗黙知、既存システム、社内IT、SES、業務部門の分断が、AI実装の大きな障害になる可能性があります。

仮説

今後、FDEという名称そのものは企業ごとに分化し、AI Deployment Engineer、Applied AI Engineer、AI Builder、AI Orchestrator、Agentic AI Consultantなどの名称に広がる可能性があります。

日本では、外部からFDEを大量採用するより、社内IT、業務部門、外部AIエンジニアを組み合わせた小規模実装チームから始める方が現実的です。

FDEを導入しても、個別案件の学びを共通基盤やプロダクトへ還流できなければ、高級SES化するリスクが高いと考えられます。

まとめ：2026年6月8日時点で見るべき変化

2026年6月8日の調査で最も重要なのは、FDEという言葉そのものが増えているかどうかではありません。

本当に見るべきなのは、AI導入の責任がどこへ移っているかです。

これまでのAI導入は、モデル選定、チャットUI、PoC、研修、プロンプト活用に注目が集まりがちでした。しかし、海外の主要企業の動きを見る限り、焦点は次の段階へ移りつつあります。

AIをどう業務に接続するか。
誰が現場に入り、暗黙知を構造化するか。
誰がデータ、権限、監査、例外処理を設計するか。
誰が導入後の成果を測定し、改善を続けるか。

ここを担う人材や組織が、FDEであり、AI Deployment Engineerであり、Applied AI Engineerであり、AI Builderであり、AI Orchestratorなのだと考えられます。

日本企業にとっての教訓は明確です。

FDEという肩書きを輸入するだけでは不十分です。
必要なのは、AI導入の実装責任を誰が持つのかを明確にすることです。

社内IT、業務部門、HR、外部ベンダー、コンサル、SIerの役割を整理し、暗黙知をAIに渡せる形へ変換し、PoCで終わらせず、本番運用と改善まで接続する。

そこまでできて初めて、FDE的な役割は意味を持ちます。

次回以降も、「FDEという名称の有無」だけでなく、各社がどのようにAI実装責任を組織化しているかを、調査日ベースで継続確認していきます。

参照URL一覧

前回記事：
https://kaichitsukai.com/2026/06/01/%e9%80%b1%e6%ac%a1fde-watch%ef%bc%9afde%e3%81%af%e3%80%8cai%e5%b0%8e%e5%85%a5%e8%81%b7%e3%80%8d%e3%81%8b%e3%82%89%e3%80%8c%e6%a5%ad%e5%8b%99%e5%a4%89%e9%9d%a9%e3%81%ae%e5%ae%9f%e8%a3%85%e8%b2%ac/

Palantir：
https://blog.palantir.com/connecting-agents-to-decisions-277dee8ddb40
https://palantir.com/docs/foundry/announcements/2026-01/
https://palantir.com/docs/foundry/announcements/2026-03/
https://palantir.com/docs/foundry/announcements/2026-05/
https://palantir.com/docs/foundry/platform-overview/overview/

OpenAI：
https://openai.com/index/openai-launches-the-deployment-company/
https://openai.com/careers/ai-deployment-engineer-seoul-south-korea/
https://openai.com/careers/partner-ai-deployment-engineer-san-francisco/
https://openai.com/careers/search/?q=deployment
https://openai.com/careers/forward-deployed-engineer-%28fde%29-nyc-new-york-city/

Anthropic：
https://www.anthropic.com/careers/jobs
https://www.anthropic.com/careers/jobs/5057647008
https://www.anthropic.com/careers/jobs/5057258008

Salesforce：
https://www.salesforce.com/ap/blog/forward-deployed-engineer/
https://www.salesforce.com/ap/blog/author/andrew-luther/
https://www.salesforce.com/ap/blog/category/agentforce/

ServiceNow：
https://www.servicenow.com/workflow/ai/ai-orchestrator-most-important-ai-job.html
https://www.servicenow.com/jp/workflow/ai/ai-orchestrator-most-important-ai-job.html

Box：
https://blog.box.com/introducing-box-automate-ai-powered-workflow-orchestration
https://blog.box.com/how-were-going-ai-first-workflow-inside-box
https://blog.box.com/how-box-automate-orchestrates-agentic-workflows
https://blog.box.com/workflows-dont-just-do-decide-box-automate-redesigns-enterprise-automation-box-customers
https://blog.box.com/box-agent-launch
https://blog.box.com/real-reason-ai-isnt-delivering-roi-youre-automating-wrong-way

EY：
https://www.ey.com/en_uk/newsroom/2026/04/ey-launches-fde-roles
https://careers.ey.com/ey/job/New-York-Forward-Deployed-Engineer-Applied-AI-Manager-Financial-Services-Consulting-NY-10001-8604/1393514533/
https://careers.ey.com/ey/job/New-York-Forward-Deployed-Engineer-Applied-AI-Senior-Financial-Services-Consulting-NY-10001-8604/1393540633/
https://careers.ey.com/ey/job/New-York-Forward-Deployed-Engineer-Applied-AI-Senior-Manager-Financial-Services-Consulting-NY-10001-8604/1393575733/

PwC：
https://jobs.us.pwc.com/job/new-york/acceleration-center-agentic-ai-and-machine-learning-developer-experienced-associate/932/95591450096
https://jobs.us.pwc.com/job/new-york/acceleration-center-agentic-ai-and-machine-learning-developer-senior-associate/932/95625372864

KPMG：
https://kpmg.com/ca/en/careers/experienced-hires/ai.html
https://kpmg.com/ee/en/insights/2026/05/Global-AI-Pulse.html
https://kpmg.com/in/en/insights/2026/04/ai-pulse-q1-2026.html

Microsoft：
https://www.microsoft.com/en/ai/agent-factory
https://www.microsoft.com/ja-jp/ai/agent-factory
https://cdn-dynmedia-1.microsoft.com/is/content/microsoftcorp/microsoft/bade/documents/products-and-services/en-us/ai/The-Microsoft-Agent-Factory-white-paper-Feb-2026.pdf
https://news.microsoft.com/source/2026/05/21/ey-and-microsoft-announce-global-initiative-to-help-clients-scale-ai-enterprisewide-value-creation-and-move-beyond-experimentation/

Google Cloud：
https://cloud.google.com/blog/products/ai-machine-learning/introducing-gemini-enterprise-agent-platform
https://cloud.google.com/blog/topics/google-cloud-next/welcome-to-google-cloud-next26
https://cloud.google.com/blog/ja/products/ai-machine-learning/introducing-gemini-enterprise-agent-platform
https://cloud.google.com/blog/ja/topics/google-cloud-next/welcome-to-google-cloud-next26

AWS：
https://www.amazon.jobs/en/search?base_query=sagemaker&city=&country=&county=&invalid_location=false&latitude=&loc_group_id=&loc_query=&longitude=&region=
https://aws.amazon.com/blogs/apn/new-agentic-ai-categories-for-aws-ai-competency-partners/
https://aws.amazon.com/blogs/apn/tag/ai-agents/
https://aws.amazon.com/blogs/apn/accenture-and-aws-accelerate-data-transformation-with-agentic-ai/
https://aws.amazon.com/blogs/machine-learning/beyond-pilots-a-proven-framework-for-scaling-ai-to-production/

ReceiptRoller：
https://receiptroller.co/en/technotes?keyword=Customer+Feedback
https://receiptroller.co/en/technotes?keyword=delta-echo

SVPG：
https://www.svpg.com/forward-deployed-engineers/

MarketWatch：
https://www.marketwatch.com/story/anthropic-and-openai-are-following-palantirs-playbook-as-they-seek-to-grow-ai-usage-c37ca6f2

LayerX：
https://tech.layerx.co.jp/entry/ai-llm-fde
https://tech.layerx.co.jp/entry/fde-2025E
https://tech.layerx.co.jp/entry/fde-intern
https://tech.layerx.co.jp/entry/2026/05/21/111742

Loglass：
https://hrmos.co/pages/loglass/jobs/1813462408235663396227
https://hrmos.co/pages/loglass/jobs/1813462408235663396269

SB OAI Japan：
https://www.softbank.jp/corp/news/press/sbkk/2026/20260206_01/

週刊 AI Governance Watch

by 塚井海地

本記事で得られる3つのポイント

  • EU AI Actは「厳格化一辺倒」ではなく、実装可能性を重視した運用フェーズへ移行しつつある
  • AI GovernanceはTrustworthy AIから、Agent Governance・Runtime Oversight・AI Securityへ明確に分化している
  • 企業実装の中心論点は「モデル性能」から「権限制御・監査ログ・エージェント統制」へ移行している

なぜ重要か

AI競争の本質はモデル性能競争から、AIをどのように統治・監査・制御するかというガバナンス競争へ移行し始めています。

1. 今週の重要アップデート

OECD

事実

OECDはOECD.AI Policy Observatoryの拡張を継続しており、2026年には「OECD.AI Index」を公表しました。

URL:
https://oecd.ai/

URL:
https://www.oecd.org/en/publications/2026/02/oecd-ai-observatory-index_8f5fa0f2.html

同Indexは各国のAI能力だけでなく、AIガバナンス実装状況の比較を可能にする政策評価ツールとして位置付けられています。

分析

Trustworthy AIを理念として扱う段階から、各国のAI Governance成熟度を定量評価する段階へ移行しつつあります。

EU AI Act

事実

EU AI Actは2024年8月に発効済みであり、主要条項は2026年8月から本格適用が進む予定です。

URL:
https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai

URL:
https://artificialintelligenceact.eu/implementation-timeline/

GPAI（General Purpose AI）関連義務は既に段階的適用が始まっており、AI Officeによる監督体制も整備が進められています。

前回からの変化

欧州議会とEU加盟国は、Omnibus VIIパッケージの中で一部高リスクAI規制の適用時期を後ろ倒しする暫定合意に到達しました。

分析

規制緩和というより、

  • 実装負荷
  • 適合性評価不足
  • 企業側の準備遅れ

に対応する現実的調整と見る方が適切です。

EUは依然として世界で最も包括的なAIガバナンス体制を維持しています。

2. リージョン別動向

EU

事実

GPAIプロバイダーには以下が求められています。

  • 技術文書管理
  • 評価結果の保存
  • AI Officeへの提出体制
  • 透明性確保

URL:
https://artificialintelligenceact.eu/article/53/

分析

実質的には「モデル開発管理規制」が始まったと言えます。

米国

事実

NIST AI RMFは引き続き米国企業の事実上の標準フレームワークとなっています。

URL:
https://www.nist.gov/itl/ai-risk-management-framework

NIST AI 600-1（Generative AI Profile）は生成AI特有のリスク管理を定義しています。

対象リスク例：

  • Confabulation
  • Information Integrity
  • Data Privacy
  • Information Security
  • Value Chain Risk

分析

NIST AI RMFは「AI Governance OS」のような役割を担い始めています。

日本

事実

2026年3月31日にAI Guidelines for Business Ver1.2が公開されています。

URL:
https://oecd.ai/en/dashboards/policy-initiatives

日本の方針は依然として自主ガバナンス中心です。

分析

EU型の法規制よりも、

  • ガイドライン
  • リスクベース運用
  • 業界協調

を重視する方向性が継続しています。

韓国

事実

AI Basic Act関連の制度設計が継続しており、高影響AIや信頼性評価が主要テーマとなっています。

分析

韓国は産業育成と規制を同時に進めるバランス型モデルを志向しています。

シンガポール／ASEAN

事実

AI VerifyおよびModel AI Governance Frameworkが引き続き中心的役割を担っています。

分析

欧州型の法規制ではなく、

  • 実装可能性
  • 相互運用性
  • 企業導入

を重視するモデルが強化されています。

英国

事実

AI Safety Instituteを軸とした評価体制が継続しています。

分析

英国は法規制主導ではなく、

  • Frontier Model Evaluation
  • Safety Testing
  • 実証評価

を強みとする独自路線を維持しています。

中国

事実

生成AI規制、アルゴリズム管理、コンテンツ管理体制が継続しています。

分析

Trustworthy AIというより、

国家安全保障型AI Governance

として理解する方が実態に近い状況です。

UAE／サウジアラビア

事実

国家AI戦略とAI投資拡大が継続しています。

分析

AI Governanceよりも、

  • 国家競争力
  • データ主権
  • AI産業誘致

が主要目的です。

オーストラリア／カナダ

事実

両国ともリスクベース型AI Governance整備を継続しています。

分析

EU法体系を参考にしつつ、より実務導入しやすい制度設計を模索しています。

3. Agent Governance / Runtime Oversight

事実

Agentic AI向けガバナンス研究が急速に増加しています。

URL:
https://arxiv.org/abs/2604.04604

URL:
https://arxiv.org/abs/2510.25863

研究では以下が重点課題として整理されています。

  • Runtime Behavioral Drift
  • Human Oversight
  • External Tool Control
  • Multi-Agent Traceability
  • Runtime Monitoring
  • Auditability

分析

Agent Governanceは既にAI Governanceの下位概念ではありません。

独立した管理領域へ成長しています。

4. AI Security / AI Safety

事実

NIST AI 600-1とOWASP系の実務コミュニティでは以下が共通課題になっています。

  • Prompt Injection
  • Supply Chain Risk
  • Tool Abuse
  • Data Leakage
  • Autonomous Agent Risk

分析

AI Securityはサイバーセキュリティの一部ではなく、

「AI Runtime Security」

として独立分野化しています。

5. 主要企業の実装動向

Palantir

分析

引き続き、

  • Permission Layer
  • Ontology
  • Auditability
  • Human-in-the-loop

が差別化要素です。

AI Governance実装企業として最も完成度が高いポジションを維持しています。

OpenAI

分析

Enterprise市場では、

  • Agent運用
  • API Governance
  • Evaluation

が中心テーマになっています。

Anthropic

分析

Constitutional AIとResponsible Scaling Policyが引き続き差別化要素です。

Google

分析

Geminiの企業導入拡大に伴い、

  • Responsible AI
  • Security Controls
  • Governance Framework

が重要性を増しています。

Microsoft

分析

Copilot展開拡大により、

  • Compliance
  • Security
  • Enterprise Governance

が中核機能になっています。

IBM

分析

watsonxを中心に、

  • AI Governance
  • Explainability
  • Monitoring

を強化しています。

xAI

分析

Grok関連議論を背景に、

  • Safety Controls
  • Governance Transparency

への関心が高まっています。

OneTrust

分析

Privacy Governanceから、

AI Governance Platform企業へポジションを拡大しています。

6. 前回からの主な変化

今回は初回レポートのため比較対象はありません。

今後は以下を継続追跡します。

  • EU AI Act施行スケジュール変更
  • GPAI Code of Practice
  • NIST AI RMF Profile追加
  • AI Security脅威動向
  • Agent Governance標準化
  • ISO/IEC 42001実装事例
  • Enterprise Governance Platform進化

7. 今週の分析

Trustworthy AIは終わっていません。

むしろ分化しています。

進化の流れは以下です。

AI Ethics
↓
Trustworthy AI
↓
Responsible AI
↓
AI Governance
↓
AI Safety
↓
AI Security
↓
Agent Governance
↓
Runtime Oversight
↓
Multi-Agent Oversight

現在の最大テーマは、

「AIをどう作るか」

ではなく

「AIをどう統治するか」

です。

8. 来週以降の注目点

  • EU AI Office関連実装ガイド
  • GPAI Code of Practice
  • ISO/IEC 42001採用事例
  • Agent Governance標準化
  • Runtime Security製品群
  • AI監査ログ標準
  • Multi-Agent監視技術
  • AI権限制御アーキテクチャ

9. 参照ソース一覧

https://oecd.ai

https://www.oecd.org/en/publications/2026/02/oecd-ai-observatory-index_8f5fa0f2.html

https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai

Implementation Timeline
Article 53: Obligations for Providers of General-Purpose AI Models

https://www.nist.gov/itl/ai-risk-management-framework

https://oecd.ai/en/dashboards/policy-initiatives

https://arxiv.org/abs/2604.04604

https://arxiv.org/abs/2510.25863

週次FDE Watch：FDEは「AI導入職」から「業務変革の実装責任者」へ

by 塚井海地

本記事で得られる3つのポイント

  1. 海外ではFDE／Forward Deployed Engineerが、Palantir由来の特殊職種から、OpenAI、Anthropic、Salesforce、EY、AWS、Microsoft周辺へ広がる「AI実装モデル」になりつつある。
  2. 直近の焦点は、単なるPoC支援ではなく、AIエージェントを業務・データ・権限・評価・運用に接続する「本番化の責任」に移っている。
  3. 日本企業が表面的にFDEを輸入すると、従来のSES・SI・社内ITの焼き直しになる。鍵は、暗黙知の構造化、業務オーナーの明確化、実装後の運用責任である。

なぜ重要か：FDEは「AIを入れる人」ではなく、「AIで業務の意思決定と実行を変える人材モデル」になり始めているためです。

1. 今週の結論

今週の海外動向では、FDEの潮流が明確に次の段階へ進んでいます。OpenAIは「OpenAI Deployment Company」を立ち上げ、Tomoro買収によりForward Deployed Engineersを初日から組み込むと説明しています。これは、AIモデルの販売だけではなく、顧客業務への実装・ワークフロー再設計・定着化までを事業化する動きです。
URL: https://openai.com/index/openai-launches-the-deployment-company/
URL: https://openai.com/business/the-openai-deployment-company/

AnthropicもApplied AIチームでForward Deployed Engineerを募集しており、顧客に直接入り込み、Claudeを使った業務アプリケーションを出荷する役割として定義しています。OpenAIとAnthropicの双方が「モデル提供会社」から「実装会社／deployment company」的な機能を強めている点が、今週の最重要シグナルです。
URL: https://job-boards.greenhouse.io/anthropic/jobs/4985877008
URL: https://www.anthropic.com/careers/jobs?939688b5_page=2&tblci=Giancarlo+Niutta

加えて、SalesforceはAgentforce領域でForward Deployed Engineer職を複数掲出しています。Agentforceを使った自動化業務プロセス、Blueprint、個別顧客向けのAgentic System構築を担う職種としており、FDEがSaaS企業のAIエージェント導入部隊にも拡張されていることが確認できます。
URL: https://careers.salesforce.com/en/jobs/jr339744/forward-deployed-engineer/
URL: https://careers.salesforce.com/en/jobs/jr343861/forward-deployed-engineer/

2. 事実：海外一次情報で確認できた主要アップデート

2.1 Palantir：OntologyがAIエージェント実装の中核に

Palantirは、Ontologyを「企業の現実」を表現し、人間とAIエージェントが業務フロー上で協働する基盤として位置づけています。直近のFoundry May 2026 Announcementsでは、Ontology MCPにより外部AIエージェントがOntology上のオブジェクト、アクション、クエリ関数へ権限管理付きで接続できると説明されています。
URL: https://palantir.com/docs/foundry/announcements/2026-05/
URL: https://palantir.com/docs/foundry/architecture-center/ontology-system/
URL: https://palantir.com/docs/foundry/aip/overview/

これは、FDEが単に現場で個別開発するだけでは不十分で、業務概念・権限・アクション・監査を含む「企業OS」へAIを接続する必要がある、というPalantir型の思想を補強しています。古くて新しい話ですが、結局、良い料理には良い出汁が要るということです。AIも同じで、業務データと文脈の出汁がなければ味が決まりません。

2.2 OpenAI：Deployment CompanyとFDEを明示

OpenAIは、OpenAI Deployment Companyを、企業がAIシステムを本番業務で信頼して使えるよう支援する会社として説明しています。ワークフロー再設計、チーム横断の導入、運用変革までを射程に入れており、Tomoro買収によってFDE経験者を取り込むとしています。
URL: https://openai.com/index/openai-launches-the-deployment-company/
URL: https://openai.com/business/the-openai-deployment-company/

またOpenAIのAI Deployment Engineer職は、顧客のGenAIユースケースをバックログ化し、プロトタイプから本番化まで技術支援する役割として記載されています。
URL: https://openai.com/careers/ai-deployment-engineer-large-enterprise-london-uk/

2.3 Anthropic：Applied AIの中核職としてFDEを採用

AnthropicのForward Deployed Engineer, Applied AIは、戦略顧客に直接入り、AIアプリケーションを出荷し、Claudeの企業導入を加速する役割です。求人一覧でもApplied AI Architect、Applied AI Engineer、Manager of Forward Deployed Engineeringなど、周辺職種が多数確認できます。
URL: https://job-boards.greenhouse.io/anthropic/jobs/4985877008
URL: https://www.anthropic.com/careers/jobs?939688b5_page=2&tblci=Giancarlo+Niutta

2.4 Accenture：Palantir連携とAI実装力の拡張

AccentureはPalantirとのグローバル戦略パートナーシップを拡大し、Accenture Palantir Business Groupを立ち上げています。狙いは、サイロ化したデータを統合し、企業のAI再発明と業務意思決定を支援することです。
URL: https://newsroom.accenture.com/news/2025/accenture-and-palantir-expand-global-strategic-partnership-to-drive-ai-reinvention

さらに2026年1月には、Sovereign AIがEMEAの次世代AIインフラ構築でAccentureとPalantirを選定したと発表されています。
URL: https://newsroom.accenture.com/news/2026/sovereign-ai-selects-accenture-and-palantir-to-help-build-next-generation-ai-infrastructure-across-emea

2.5 Salesforce：Agentforce FDEが明確化

SalesforceはAgentforce関連でFDE職を掲出し、顧客エンゲージメントとプラットフォーム革新の交差点に立つ職種と説明しています。別の求人では、FDEを「技術者かつ戦略パートナー」とし、Agentforceを使った個別AIソリューションを直接設計・開発・実装する役割としています。
URL: https://careers.salesforce.com/en/jobs/jr339744/forward-deployed-engineer/
URL: https://careers.salesforce.com/en/jobs/jr343861/forward-deployed-engineer/
URL: https://www.salesforce.com/ap/blog/forward-deployed-engineer/

2.6 ServiceNow：Autonomous WorkforceとAI Orchestrator

ServiceNowはAutonomous Workforceを掲げ、Web・音声エージェント、Now Assist Explorer、ServiceNow Lensなどで業務アクションを自律化する方向を示しています。Knowledge 2026でも、AIは将来構想ではなく、企業内で実際に仕事をしているというメッセージが強調されています。
URL: https://www.servicenow.com/platform/autonomous-workforce.html
URL: https://www.servicenow.com/workflow/news/top-moments-knowledge-2026.html

ServiceNowはFDEという名称よりも、AI OrchestratorやAutonomous Workforceという言葉で、業務・人・AIエージェントの調整役を前面に出しています。
URL: https://www.servicenow.com/latam/workflow/ai/ai-orchestrator-most-important-ai-job.html

2.7 Box：AI-first業務再設計とBox Automate

Boxは、AI-first化とは単発の変革ではなく、重要な業務ワークフローをBox AI Agentsと自動化を前提に再設計することだと述べています。Box Automateは、コンテンツを構造化されたアクションに変え、ツール乱立や手作業のプロセス管理を減らす狙いです。
URL: https://blog.box.com/how-were-going-ai-first-workflow-inside-box
URL: https://blog.box.com/introducing-box-automate-ai-powered-workflow-orchestration

2.8 EY・PwC・KPMG・Deloitte：Big4も「実装職」へ寄る

EYは2026年4月、Forward Deployed Engineer AI rolesを発表し、クライアントチーム内でAIを設計・構築・運用化するシニアAIエンジニアを採用するとしています。
URL: https://www.ey.com/en_uk/newsroom/2026/04/ey-launches-fde-roles

PwCはAgentic AIによる workforce redesign を論じ、IT部門が単なる要望対応ではなく、インテリジェントワークフローを設計しAIシステムを管理する役割へ変わるとしています。
URL: https://www.pwc.com/us/en/tech-effect/ai-analytics/agentic-ai-workforce-redesign.html

KPMG CanadaはAI Transformationチーム拡張の一環としてAI Buildersを募集し、社内業務に直接組み込まれるエージェント、ツール、スキルを設計・構築・スケールする職種と説明しています。
URL: https://kpmg.com/ca/en/careers/experienced-hires/ai.html

DeloitteはFDEという名称の明確な更新は確認できませんでしたが、AIが人間の判断・創造性・意思決定を補強するように仕事と役割を再設計すべきだと論じています。
URL: https://www2.deloitte.com/us/en/insights/industry/technology/technology-media-telecom-outlooks/sports-industry-outlook.html

2.9 Microsoft・Google Cloud・AWS：クラウド勢は「エージェント本番化」に寄る

MicrosoftはEYとのグローバル施策で、業界別AIソリューション、ワークフォースのアップスキリング、チェンジマネジメント、継続最適化を組み合わせると発表しています。またMicrosoft Agent Factoryの資料では、顧客がパイロットから本番へ進むためにForward Deployed Engineeringとパートナーを利用できると記載されています。
URL: https://news.microsoft.com/source/2026/05/21/ey-and-microsoft-announce-global-initiative-to-help-clients-scale-ai-enterprisewide-value-creation-and-move-beyond-experimentation/
URL: https://cdn-dynmedia-1.microsoft.com/is/content/microsoftcorp/microsoft/bade/documents/products-and-services/en-us/ai/The-Microsoft-Agent-Factory-white-paper-Feb-2026.pdf

Google CloudはNext ’26でAgentic Enterpriseを前面に出し、Gemini Enterprise Agent Platformを「エージェントの構築・拡張・統治・最適化」の基盤として発表しています。日本語ブログでも同内容が展開されています。
URL: https://cloud.google.com/blog/topics/google-cloud-next/welcome-to-google-cloud-next26
URL: https://cloud.google.com/blog/products/ai-machine-learning/introducing-gemini-enterprise-agent-platform
URL: https://cloud.google.com/blog/ja/products/ai-machine-learning/the-new-gemini-enterprise-one-platform-for-agent-development

AWSでは、Forward Deployed AI IntegratorやSenior Forward Deployed Deep Learning Architect、GenAI Innovation Center関連職が確認できます。AWS側の表現は「FDEそのもの」よりも、顧客現場に入り、生成AIソリューションを構築・実装・変革成果へつなげるチームという色が強いです。
URL: https://amazon.jobs/en/jobs/10430718/forward-deployed-ai-integrator-data-center-engineering
URL: https://www.amazon.jobs/en/jobs/10376735/senior-forward-deployed-deep-learning-architect-generative-ai-innovation-center
URL: https://www.amazon.jobs/jobs/10423646/head-of-ai-transformation–apjc-generative-ai-innovation-center

3. 今週の更新有無

優先組織・情報源更新有無確認内容URL
Palantir BlogありOntologyとエージェント意思決定接続に関する記事を確認https://blog.palantir.com/connecting-agents-to-decisions-277dee8ddb40
Palantir Foundry/AIP Docsあり2026年5月更新でOntology MCPを確認https://palantir.com/docs/foundry/announcements/2026-05/
OpenAI NewsありOpenAI Deployment Company発表、Tomoro買収、FDE明記https://openai.com/index/openai-launches-the-deployment-company/
OpenAI CareersありAI Deployment Engineer職を確認https://openai.com/careers/ai-deployment-engineer-large-enterprise-london-uk/
Anthropic CareersありForward Deployed Engineer, Applied AIを確認https://job-boards.greenhouse.io/anthropic/jobs/4985877008
Anthropic Applied AIありApplied AI Architect / Engineer / FDE系職種多数https://www.anthropic.com/careers/jobs?939688b5_page=2&tblci=Giancarlo+Niutta
Accenture NewsroomありPalantir連携、Sovereign AI案件を確認https://newsroom.accenture.com/news/2026/sovereign-ai-selects-accenture-and-palantir-to-help-build-next-generation-ai-infrastructure-across-emea
Accenture Careers不明今回の検索範囲ではFDE職の一次情報は明確に確認できずhttps://www.accenture.com/us-en/careers
Salesforce Blog/NewsありFDE解説記事とAgentforce文脈を確認https://www.salesforce.com/ap/blog/forward-deployed-engineer/
Salesforce CareersありAgentforce Forward Deployed Engineer職を複数確認https://careers.salesforce.com/en/jobs/jr343861/forward-deployed-engineer/
ServiceNow Blog/Autonomous WorkforceありAutonomous Workforce、AI Orchestrator、Knowledge 2026関連を確認https://www.servicenow.com/platform/autonomous-workforce.html
ServiceNow Careers不明今回の検索範囲ではFDE名の職種は明確に確認できずhttps://careers.servicenow.com/
Box BlogありAI-first workflow、Box Automate、AI workflow automationを確認https://blog.box.com/how-were-going-ai-first-workflow-inside-box
Deloitte AI/Agentic AIあり仕事・役割再設計の論点を確認https://www2.deloitte.com/us/en/insights/industry/technology/technology-media-telecom-outlooks/sports-industry-outlook.html
Deloitte Careers不明今回の検索範囲ではFDE職の明確な一次情報は確認できずhttps://www.deloitte.com/global/en/careers.html
EY NewsroomありEYがFDE AI rolesを発表https://www.ey.com/en_uk/newsroom/2026/04/ey-launches-fde-roles
EY CareersありForward Deployed Engineer – Applied AI職を確認https://careers.ey.com/ey/job/New-York-Forward-Deployed-Engineer-Applied-AI-Manager-Financial-Services-Consulting-NY-10001-8604/1393514533/
PwC InsightsありAgentic AI workforce redesign、AI agentsを確認https://www.pwc.com/us/en/tech-effect/ai-analytics/agentic-ai-workforce-redesign.html
PwC CareersありAgentic AI / ML Developer職を確認https://jobs.us.pwc.com/job/new-york/risk-architecture-agentic-ai-and-machine-learning-developer-experienced-associate/932/95591450096
KPMG InsightsありAgentic AI workforce、Agentic Opportunityを確認https://kpmg.com/ca/en/insights/2026/05/the-agentic-shift-ai-next-phase.html
KPMG CareersありAI Builders募集を確認https://kpmg.com/ca/en/careers/experienced-hires/ai.html
Microsoft Marketplace/News/Build/Ignite/CopilotありEY連携、Copilot Studio、Agent Factoryを確認https://news.microsoft.com/source/2026/05/21/ey-and-microsoft-announce-global-initiative-to-help-clients-scale-ai-enterprisewide-value-creation-and-move-beyond-experimentation/
Google Cloud BlogありAgentic Enterprise、Gemini Enterprise Agent Platformを確認https://cloud.google.com/blog/products/ai-machine-learning/introducing-gemini-enterprise-agent-platform
Google Cloud Japan BlogありGemini Enterprise日本語記事、Agentic AI Hackathon等を確認https://cloud.google.com/blog/ja/products/ai-machine-learning/the-new-gemini-enterprise-one-platform-for-agent-development
AWS Blog/APN BlogありAWS Transform、AI agentsによるモダナイゼーション文脈を確認https://aws.amazon.com/blogs/apn/category/enterprise-strategy/
AWS Marketplace不明今回の検索範囲ではFDE関連の明確な更新は確認できずhttps://aws.amazon.com/marketplace
Amazon JobsありForward Deployed AI Integrator、Forward Deployed Deep Learning Architectを確認https://amazon.jobs/en/jobs/10430718/forward-deployed-ai-integrator-data-center-engineering
ReceiptRoller FDE seriesありFDE連載 Chapter 1 / Chapter 2を確認https://receiptroller.co/en/technotes?keyword=last-mile
Pragmatic EngineerありFDE再加熱、Google Cloud FDE採用増の言及を確認https://blog.pragmaticengineer.com/the-pulse-forward-deployed-engineering-heats-up-again/
SVPG更新なし2025年9月記事が主要参照。今週の新規更新は確認できずhttps://www.svpg.com/forward-deployed-engineers/
Pave更新なしFDE報酬比較記事を確認。今週の新規更新は確認できずhttps://www.pave.com/blog-posts/forward-deployed-engineer-on-the-rise
IT BrewありFDEの必要スキル、2026年のFDE化に関する記事を確認https://www.itbrew.com/stories/2026/03/12/what-does-it-take-to-become-a-forward-deployed-engineer
MarketWatchありOpenAI/AnthropicがPalantir型を追う分析記事を確認https://www.marketwatch.com/story/anthropic-and-openai-are-following-palantirs-playbook-as-they-seek-to-grow-ai-usage-c37ca6f2
LayerX FDE / Ai WorkforceありFDE募集・振り返り・Ai Workforce関連を確認https://tech.layerx.co.jp/entry/fde-2025E
Loglass FDEありLoglass AI事業でFDE募集、顧客経営課題とAI実装を接続https://hrmos.co/pages/loglass/jobs/1813462408235663396227
JDSC FDE不明今回の検索範囲では明確なFDE更新を確認できずhttps://jdsc.ai/
SB OAI JapanありOpenAI Frontierを活用しCrystal intelligenceを日本企業向けに展開予定https://www.softbank.jp/en/corp/news/press/sbkk/2026/20260206_01/
Salesforce Japanあり日本語採用ページでMissionforce FDE等を確認https://careers.salesforce.com/jp/
国内コンサル/SIer不明FDE名称の明確な一次情報は限定的。AI導入・生成AI支援は多数あるがFDEとは区別が必要—
日本のDX・暗黙知・SES・社内IT・HR・早期退職/構造改革あり直接FDEではないが、日本企業の労働力不足・AIロボット検討など実装需要を示す情報を確認https://www.reuters.com/business/autos-transportation/one-three-japan-firms-using-or-considering-ai-robots-2026-05-20/

4. 分析：FDEの本質は「職種名」ではなく「実装責任の再配置」

FDEブームを表面的に見ると、「エンジニアが顧客先に行く職種が増えた」という話に見えます。しかし、今回の一次情報を並べると、本質はもう少し深いところにあります。

第一に、AIエージェントはSaaSのようにログインすれば即価値が出るものではありません。顧客企業の業務プロセス、権限、例外処理、監査、データ品質、人間の判断ポイントに接続して初めて価値が出ます。PalantirのOntology、OpenAIのDeployment Company、Google CloudのAgentic Enterprise、ServiceNowのAutonomous Workforceはいずれも、この「業務接続」の重要性を示しています。

第二に、FDEは従来のプリセールス、カスタマーサクセス、SI、PM、データエンジニアの単純な合体ではありません。SVPGは、FDEを顧客環境に深く入り、真の問題を理解し、成果を届けるProduct Creator的役割として説明しています。つまり、FDEは「要件を聞いて作る人」ではなく、「何を作れば業務成果が出るかを現場で発見し、実装し、プロダクトへ還流させる人」です。
URL: https://www.svpg.com/forward-deployed-engineers/

第三に、FDEには反論もあります。Business Insiderは、元Snowflake CROのChris Degnan氏がFDEを「glorified professional services」と批判し、技術負債や保守リスクを残す可能性を指摘したと報じています。これは重要な警鐘です。FDEを名乗っても、顧客ごとの特注開発を乱発し、共通プロダクトへ学習を戻せなければ、AI時代の高級SESになってしまいます。
URL: https://www.businessinsider.com/snowflake-cro-forward-deployed-engineers-ai-job-2026-5

5. 日本企業への実務示唆

5.1 暗黙知を「AIに読める業務構造」へ変換する

日本企業の強みは、現場の暗黙知、例外対応、取引先ごとの慣行、ベテラン社員の判断にあります。一方で、AIエージェントは暗黙知をそのまま扱えません。FDE的な役割が必要になるのは、ここです。

実務上は、まず以下を整理する必要があります。

項目FDEが構造化すべき内容
業務目的何のKPIを改善するのか
判断基準ベテランが何を見て判断しているか
例外処理どのケースで人間に戻すか
権限AIが実行してよい範囲、承認が必要な範囲
データどのデータが正で、どこに欠損・揺れがあるか
評価成功・失敗をどう測るか
運用誰が保守し、改善し、責任を持つか

ここを飛ばして「生成AIを入れました」と言っても、だいたい立派なデモで終わります。展示会では拍手、現場では沈黙。これは避けるべきです。

5.2 SES・SI・社内ITとの違いを明確にする

日本でFDEを導入する際、最大のリスクは既存のSESやSIの看板を掛け替えるだけになることです。

FDEと従来型SI/SESの違いは、成果責任と学習ループにあります。FDEは顧客先で個別課題を解くだけでなく、その知見を再利用可能なプロダクト、テンプレート、エージェント設計、業務Ontology、評価基盤へ戻す必要があります。

比較軸従来型SES/SI本来のFDE
起点要件定義書業務成果・現場課題
主な責任開発・納品実装・定着・成果・学習還流
顧客接点PM/営業中心エンジニアが現場に深く入る
成果物システム、ドキュメント業務変革、AIワークフロー、再利用可能な知見
リスク受託開発化特注化・技術負債化
成功条件納期・予算遵守業務KPI改善、運用定着、プロダクト進化

5.3 HRは「AI人材採用」ではなく「業務実装人材の再定義」を行う

FDEは高度なAIエンジニアだけでは成立しません。必要なのは、ソフトウェア実装力、業務理解、顧客折衝、データ設計、チェンジマネジメントを横断する人材です。

日本企業では、次の人材がFDE候補になります。

候補人材強み補うべき点
社内ITの業務システム担当社内業務と既存システムを理解AI/LLM実装、プロダクト思考
SIerの上流SE業務整理と顧客調整自ら手を動かす実装力、継続改善
データエンジニアデータ基盤と品質管理業務現場への入り込み
DX推進担当社内変革と部門調整技術的な実装判断
業務部門のエース暗黙知と現場信頼AIリテラシー、設計能力

早期退職や構造改革が進む企業では、現場の暗黙知が失われる前に、FDE的な人材が業務知識を構造化することが急務です。AI導入は、単なる省人化ではなく、熟練知の継承プロジェクトでもあります。

6. 仮説：日本版FDEは「外部常駐」より「内製変革チーム」から始まる

現時点の仮説として、日本企業に最も適したFDE導入モデルは、いきなり外部ベンダーのFDEを大量投入する形ではありません。むしろ、社内の業務エース、社内IT、データ担当、外部AIエンジニアを小さな混成チームにし、特定業務の成果責任を持たせる形が現実的です。

推奨する初期編成は以下です。

役割人数責任
業務オーナー1KPI、意思決定、現場調整
FDE / AI実装リード1AIワークフロー設計、実装、本番化
データ/基盤担当1データ接続、権限、監査、運用
現場キーユーザー1〜2暗黙知、例外処理、受入評価
変革PM1導入計画、教育、定着、効果測定

このチームが最初に扱うべきテーマは、全社横断の大構想ではなく、効果測定しやすい業務です。たとえば、問い合わせ一次対応、見積・契約レビュー、経営管理レポート作成、営業提案準備、社内ナレッジ検索、請求・経費・稟議の例外処理などです。

7. 来週以降の観測ポイント

来週以降は、以下を重点的に追うべきです。

  1. OpenAI Deployment Companyが、どの業界・どの職種・どのパートナー網でFDEを拡張するか。
  2. Anthropic Applied AIが、FDEと安全性・評価・ガバナンスをどう接続するか。
  3. Salesforce Agentforce FDEが、SaaS導入支援なのか、業務プロセス再設計部隊なのか。
  4. Palantir Ontology MCPが、外部AIエージェント接続の標準的な参照モデルになるか。
  5. 日本ではLayerX、Loglass、SB OAI Japan以外に、FDEを明示する企業が増えるか。
  6. 国内SIer・コンサルがFDEを名乗る場合、従来の常駐開発との差分をどこまで説明するか。

8. 編集後記：FDEは流行語にすると負ける

FDEは、肩書きとして輸入すると危険です。名刺に「Forward Deployed Engineer」と書くだけなら、横文字の勝利、現場の敗北です。

本当に重要なのは、AIを業務の中に入れ、意思決定・実行・評価・改善のループを作ることです。日本企業にとっては、FDEという言葉そのものよりも、「誰が実装責任を持つのか」「誰が暗黙知を構造化するのか」「誰がAI導入後の運用成果を見るのか」を明確にすることが先です。

今週の結論を一文で言えば、FDEはAI時代の“現場に降りるプロダクト開発”です。机上のAI戦略を、現場の業務成果へ着地させる人材モデルとして、今後も継続観測する価値があります。

FDEという職種名から考える、社内にいる「業務を知る実装人材」

by 塚井海地

海外で注目される役割を、日本企業の現場感覚に置き換えて考える

本記事で得られる3つのポイント

  • FDEという職種が、どのような役割を指しているのかを実務目線で整理できます。
  • 日本企業にも、FDEに近い役割を担っている人材がすでに存在する可能性を確認できます。
  • AI導入やDXを進める前に、社内の業務知識と実装力を見直すきっかけになります。

なぜ重要か：
AI活用やDXでは、最新ツールの選定だけでなく、業務を理解し、実際の運用に落とし込める人材が重要になります。FDEという職種名は、その役割を見直すための一つの参考材料になります。

はじめに：FDEという職種名が注目されている

最近、AI、DX、データ活用の文脈で「FDE」という言葉を見かける機会があります。

FDEとは、Forward Deployed Engineerの略です。直訳すると「前線配置型エンジニア」のような意味になります。
もともとはPalantirのような企業で語られることが多い職種で、顧客の現場に入り、業務課題を理解し、データやソフトウェアを使って実際の成果につなげる役割として知られています。

ただし、日本企業の現場に置き換えて考えると、FDEはまったく新しい概念というより、これまで日本の現場にも存在してきた役割に近い部分があります。

たとえば、業務に詳しいSE、情シスの中核担当者、現場改善に強い担当者、基幹システムに詳しい社員、既存ベンダーの実装担当者などです。

本記事では、FDEという職種名をきっかけに、日本企業の中にある「業務を知る実装人材」の価値を整理します。

FDEとは、実務的には何をする人なのか

FDEは、顧客現場に入り込み、業務課題を把握し、ソフトウェアやAI、データ基盤を使って課題解決を進めるエンジニアです。

実務の言葉に置き換えると、次のような役割です。

業務の流れを理解し、システムやデータを活用しながら、現場で成果が出るところまで実装を進める人材。

つまり、単にコードを書く人だけを指すわけではありません。
また、会議や資料作成だけを担う役割でもありません。

現場の課題を理解し、それを実際に動く仕組みに落とし込み、運用に乗せるところまで関わる点に特徴があります。

AI時代において、この役割は重要性を増しています。
AIツールは導入しただけでは成果につながりにくく、業務フロー、データ、権限、承認ルール、例外処理、運用体制と接続してはじめて効果を発揮するためです。

日本企業にも、FDEに近い役割を担う人材はいる

FDEという職種名は新しく見えますが、その役割に近い人材は日本企業にも存在します。

たとえば、次のような人材です。

日本企業にいる人材 担っている役割
情シスの中核担当者 業務部門、ベンダー、経営層の間をつなぐ
業務に詳しいSE 現場の運用、例外処理、システム制約を理解している
Excel、Access、kintone、BIなどを活用している担当者 現場の課題を把握し、小さな改善を積み上げている
基幹システムに詳しい担当者 業務フロー、データ定義、運用ルールを把握している
現場改善に強い管理職・リーダー 人、業務、システムの接点を理解している
既存ベンダーの実装担当者 顧客企業の業務特性や運用上の注意点を理解している

こうした人材は、役職名だけでは見つけにくい場合があります。

実際には、日々の業務改善、システム運用、現場調整、データ整備、レポート作成、ベンダー対応などの中で、組織の運用を支えていることが多くあります。

これからAI活用が進むほど、こうした業務理解と実装力を持つ人材の価値は高まると考えられます。

FDEという言葉を、そのまま輸入する必要はない

FDEという職種名そのものを、無理に使う必要はありません。

日本の現場感覚で見れば、「顧客の現場に入り、業務を理解し、システムを改善し、運用まで見る」という役割は、業務SE、情シス、常駐エンジニア、業務コンサル、DX推進担当と重なる部分があります。

そのため、FDEをまったく新しい職種として受け取るよりも、既存の役割を再評価するための視点として使う方が実務的です。

社内にいる「業務を知る実装人材」を、AI時代の重要な推進役として捉え直す。

このように考えると、FDEという言葉は、海外の流行語ではなく、社内人材を見直すための整理軸として使えます。

AI導入でつまずく理由は、ツール不足だけではない

AI導入が思うように進まない理由は、必ずしもAIツールの性能不足だけではありません。

実際には、次のような要因で止まるケースがあります。

よくあるつまずき 背景にある課題
PoCで終わる 本番業務に組み込む設計が不足している
現場で使われない 実際の業務フローに合っていない
AIの回答品質が安定しない データやナレッジの整理が不十分
セキュリティ部門で止まる 権限設計や監査ログの設計が曖昧
ベンダー依存が強くなる 社内側に実装内容を理解する人材が不足している
効果が測れない KPIが業務成果に結びついていない

こうした課題を解くには、AIに詳しいだけでは不十分です。

業務を理解し、データを理解し、システムを理解し、現場の運用にも配慮できる人材が必要になります。

その意味で、FDEに近い役割を担う人材は、AI導入の橋渡し役になり得ます。

社内にいるFDE型人材を見つける視点

社内にいるFDE型人材を見つける場合、肩書きだけで判断するよりも、実際に担っている役割を見ることが重要です。

たとえば、次のような特徴を持つ人材です。

  • 現場業務の流れを説明できる
  • 例外処理やイレギュラー対応を理解している
  • Excel、Access、kintone、BI、RPAなどを使って業務改善を進めた経験がある
  • 業務部門とIT部門の両方と会話できる
  • ベンダーとの会話で技術的な論点を理解できる
  • 業務上のデータが、どのように作られ、どこで使われているかを理解している
  • 業務改善を運用に乗せるところまで関わった経験がある
  • 新しいツールを、実際の業務に置き換えて考えられる

こうした人材は、必ずしもAI専門人材として採用された人とは限りません。
また、最新の技術用語に詳しいとは限りません。

しかし、AIを業務に組み込む段階では、業務の実態を理解していることが大きな強みになります。

AIをどの業務に使うべきか、どこに使うとリスクがあるか、どのデータを整備すべきかを判断するには、現場の知識が欠かせないためです。

外部人材を活用する場合も、社内の受け手が重要になる

これは、外部のFDE、AIコンサル、専門ベンダーを否定する話ではありません。

外部の専門家には、外部の専門家ならではの価値があります。
最新技術、他社事例、設計パターン、セキュリティ知見、実装スピードなど、社内だけでは補いきれない部分もあります。

ただし、外部人材を活用する場合でも、社内に受け手となる人材がいないと、導入後の運用や改善が難しくなる可能性があります。

そのため、現実的には次のような形が考えられます。

外部の専門家と、社内の業務実装人材を組み合わせる。

外部の知見と、社内の業務知識を組み合わせることで、AI導入やDXを現場に定着させやすくなります。

経営者・管理職にとっての見方

経営者や管理職にとって、FDEという職種名から得られる示唆は明確です。

AI人材を外部に求める前に、社内にいる業務実装人材を確認する。

たとえば、長年使われている業務用Excelを整備してきた担当者。
基幹システムの例外処理を理解している担当者。
各部署の業務フローを横断的に理解している人。
ベンダーとの打ち合わせで、実質的に仕様整理を担っている人。

こうした人材は、AI時代において重要な橋渡し役になる可能性があります。

これまで日常業務の中で自然に担われてきた役割を、AI活用やDXの推進役として改めて位置づけることができれば、外部依存を抑えながら実効性のある取り組みにつなげやすくなります。

小さく始めるなら、どこから取り組むべきか

社内FDE型人材を活かすといっても、いきなり全社規模で進める必要はありません。

まずは、小さな業務から始める方が現実的です。

  • 社内問い合わせ対応
  • 日報・週報の作成支援
  • 会議メモの整理
  • 請求処理や経費精算の確認作業
  • 在庫確認や棚卸し業務
  • 営業資料のたたき台作成
  • FAQやマニュアルの整備
  • ITヘルプデスクの一次対応

こうした業務は、大規模なAIシステムを導入する前でも改善に取り組みやすい領域です。

重要なのは、ツールを先に決めることではありません。
まず業務を確認し、どこに時間がかかっているのか、どこでミスが起きやすいのか、どこを改善すると現場の負担が減るのかを把握することです。

そのうえで、AI、データ、既存システムをどう活用するかを考える。
この順番が実務上は重要です。

FDEという職種名をきっかけに、既存人材の価値を見直す

FDEという職種名は、海外テック企業の文脈で注目されています。
しかし、日本企業の現場に置き換えると、すでに近い役割を担っている人材がいる可能性があります。

業務を理解している人。
システムの制約を理解している人。
現場とITの間をつなげられる人。
小さな改善を積み上げてきた人。

こうした人材の価値は、AI時代に改めて高まっています。

AIを本当に使える形にするには、現場の業務を理解している人が必要だからです。

まとめ：FDEは、社内人材を見直すためのヒントになる

FDEという職種名は、海外発の新しい言葉として見られることがあります。

しかし、その役割を日本企業の現場に置き換えると、決して特別な話だけではありません。

業務を理解し、データを読み、システムを活用し、現場で成果が出るところまで関わる人材。
そうした人材は、日本企業にも存在してきました。

これからAI活用やDXを進めるうえで大切なのは、外部から新しい肩書きの人材を探すことだけではありません。

まずは社内にいる「業務を知る実装人材」を見つけ、その価値を再評価すること。
そのうえで、必要に応じて外部の専門家やAIツールを組み合わせること。

FDEという職種名は、そのための参考材料になります。

新しい言葉をそのまま受け入れる必要はありません。
一方で、その背景にある考え方を確認することで、社内人材やAI導入の進め方を見直すきっかけになります。

Palantirの「マニフェスト」は日本でも知っておきたい論点だ

by 塚井海地

AI・防衛・公共データ、そして日本の平和主義に言及したテクノロジー企業の思想表明

本記事で得られる3つのポイント

  • Palantirが公開した「22項目のマニフェスト」で、日本の戦後平和主義がどのように言及されたのかが分かります。
  • この文書が単なる企業広報ではなく、AI・軍事・国家運営をめぐる思想表明である理由を整理します。
  • 日本の防衛DX、公共データ基盤、AIガバナンスにどのような論点が生まれるのかを考察します。

なぜ重要か：
日本について明確に言及されている文書でありながら、この論点は日本国内でまだ十分に共有されているとは言いにくいため、AI・防衛・公共データの今後を考えるうえで、内容を冷静に確認しておく価値があります。

はじめに：なぜ日本でもこの文書を知っておきたいのか

米国のデータ分析企業Palantir Technologiesが公開した「マニフェスト」が、海外のテック業界・安全保障関係者の間で議論を呼んでいます。

一方で、日本国内では、Palantirという企業名や、この文書の内容が広く一般に知られているとは言いにくい状況です。

もちろん、それ自体を問題視したり、読者を煽ったりする意図はありません。Palantirは一般消費者向けサービスを提供する企業ではなく、政府機関、軍、公共機関、大企業向けのデータ基盤を扱う企業であるため、日常生活の中で名前を目にする機会が少ないのは自然なことです。

ただし、この文書は日本にとって決して無関係ではありません。なぜなら、Palantirはこのマニフェストの中で、戦後の日本、そして日本の平和主義に明確に言及しているからです。

Palantirが公式LinkedInに投稿した「The Technological Republic, in brief.」では、戦後のドイツと日本について、「無力化は取り消されるべき」とする趣旨の主張が示されています。さらに、日本の平和主義についても、アジアのパワーバランスに影響を与え得るものとして言及されています。
参照URL：
https://www.linkedin.com/pulse/technological-republic-brief-palantir-technologies-ktdde

これは、単なる海外企業の思想表明ではありません。AI、軍事、防衛産業、公共データ、行政システム、国家安全保障が交差する時代において、日本の立ち位置そのものに関わる論点です。

Palantirとは何者か

Palantirは、米国のデータ分析・AIプラットフォーム企業です。

同社は政府機関、軍、情報機関、警察、医療、金融、製造業など、巨大で複雑なデータを扱う組織向けにシステムを提供してきました。
一般消費者向けアプリを提供する企業というより、国家・大企業・公共機関の意思決定を支えるインフラ企業と見る方が実態に近いでしょう。

Palantir公式サイトでも、同社のソフトウェアは、西側の重要な政府機関・商業組織におけるリアルタイムかつAI駆動の意思決定を支えるものとして説明されています。
参照URL：
https://www.palantir.com/

そのため、Palantirが政治的・思想的な文書を出す場合、それは「一企業の意見」にとどまりません。

同社の思想は、現実のシステム設計、軍事AI、行政データ基盤、公共調達に影響を及ぼす可能性があります。

ここが、今回のマニフェストを読むうえで非常に重要な前提です。

「マニフェスト」の正体：新規文書ではなく、著書の22項目要約

今回話題になっている文書は、Palantirが公式LinkedInおよびXで公開した「The Technological Republic, in brief.」という22項目の要約です。

この内容は、PalantirのCEOであるAlexander C. Karp氏とNicholas W. Zamiska氏による著書
『The Technological Republic: Hard Power, Soft Belief, and the Future of the West』を短く圧縮したものと位置づけられています。

Penguin Random Houseの案内では、同書は2025年2月18日にCrown Currencyから刊行され、Silicon Valleyが国家的・公共的な大課題から離れ、より軽い消費者向けサービスに知的資源を向けすぎたことへの批判として紹介されています。
参照URL：
https://sites.prh.com/technologicalrepublicpressrelease

つまり、この文書は単なるSNS投稿ではありません。

Palantirが自社の存在意義を、AI時代の国家、防衛、西側社会の再建という大きな文脈で再定義したものと見るべきです。

マニフェストの中核主張

Palantirのマニフェストは、かなり強い思想性を持っています。
細部を削ぎ落として整理すると、主張の柱は次の5つです。

1. Silicon Valleyは国家に対して道義的負債がある

Palantirは、Silicon Valleyのエンジニアやテック企業は、米国という国家の安全保障、制度、研究投資、自由な市場環境の上で成長してきたと見ています。

そのため、国家が危機に直面しているとき、テック企業は距離を置くのではなく、防衛・安全保障・公共的課題に関与すべきだ、という立場です。

これは従来の「テック企業は国家から距離を置き、自由で中立的な技術を提供する」という考え方とは大きく異なります。

アプリや広告ビジネスだけに優秀なエンジニアリングを使う時代ではない。AI時代の主戦場は国家安全保障である。

2. ソフトパワーだけでは民主主義を守れない

Palantirは、自由、民主主義、文化、外交といったソフトパワーだけでは西側社会を守れないと考えています。

そして、これからのハードパワーは、戦車や戦闘機だけでなく、ソフトウェア、AI、データ分析、リアルタイム意思決定支援によって作られると見ています。

ここにPalantirの事業領域が直結します。

戦場で何が起きているかを統合し、データを分析し、状況判断を支援し、次の行動につなげる。こうしたシステムこそが、AI時代の軍事力の中核になるという発想です。

3. AI兵器は作られる。問題は誰が作るかだ

もっとも議論を呼んでいるのが、AI兵器に関する主張です。

Palantirは、AI兵器が作られるかどうかを議論しても、敵対国は待ってくれないと見ています。
だから問題は「AI兵器を作るべきか」ではなく、「誰が、どの価値観のもとで作るか」だという論理です。

この主張は、倫理面では非常に重い問題を含みます。

人間の判断をどこまで残すのか。AIによる標的識別はどこまで許容されるのか。誤認や民間人被害をどう防ぐのか。責任の所在は誰にあるのか。

これらは、単なる技術論では済みません。

4. ドイツと日本の戦後体制に言及している

Palantirは、戦後のドイツと日本の「無力化」は取り消されるべきだという趣旨の主張をしています。
さらに、日本の平和主義について、維持されればアジアのパワーバランスを脅かす可能性がある、という見方を示しています。
参照URL：
https://www.linkedin.com/pulse/technological-republic-brief-palantir-technologies-ktdde

この点が、日本にとって特に重要です。

5. 文化相対主義や多元主義にも批判的な視点を示している

マニフェストの後半では、文化相対主義や多元主義に対する批判も展開されています。

ここは技術論というより、文明論・政治哲学の領域です。
支持する側から見れば「西側社会が自らの価値観を再確認するための議論」ですが、批判する側から見れば「文化的序列化」や「排他的な世界観」に見える部分でもあります。

日本への直接言及：なぜここが重要なのか

日本にとって最も重要なのは、マニフェストの第15項目です。

Palantirは、戦後のドイツと日本の「無力化」は取り消されるべきだという趣旨の主張をしています。
さらに、日本の平和主義について、維持されればアジアのパワーバランスを脅かす可能性がある、という見方を示しています。
参照URL：
https://www.linkedin.com/pulse/technological-republic-brief-palantir-technologies-ktdde

この表現は、日本国内では強い違和感を持たれる可能性があります。

なぜなら、日本の戦後平和主義は、単なる「消極性」ではなく、敗戦、原爆、東京大空襲、沖縄戦、戦争責任、憲法9条、日米安保、経済復興といった複雑な歴史の上に成立してきたものだからです。

もちろん、現在の国際環境において、日本が防衛力をどう整備するかは重要な論点です。

中国の軍事的台頭、台湾有事リスク、北朝鮮の核・ミサイル開発、ロシアのウクライナ侵攻以降の安全保障環境を考えれば、日本が防衛を他人任せにできないという議論には一定の現実性があります。

しかし、それでも外部の米国企業が日本の戦後平和主義を、アジアのパワーバランスという文脈で語る場合、日本側はその背景にある事業利益、地政学的意図、技術導入圧力を冷静に見なければなりません。

要するに、ここで問われているのは「日本は防衛力を強化すべきか」という単純な話ではありません。

誰の思想、誰の技術、誰のシステムに依存して、日本の安全保障と公共インフラを設計するのか。

この問いが核心です。

なぜ海外で批判されているのか

Palantirのマニフェストは、海外メディアや研究者から強い批判も受けています。

Al Jazeeraは、Palantirの文書について、AI戦争ドクトリンを推進しているとして批判的に報じました。
また、同記事では「technofascism」という表現を用いて批判する専門家の見方も紹介されています。
参照URL：
https://www.aljazeera.com/news/2026/4/20/technofascism-critics-accuse-palantir-of-pushing-ai-war-doctrine

The Vergeは、Palantirのマニフェストを皮肉交じりに解説し、日本とドイツの再軍備に関する主張を、Palantirの事業機会とも重なるものとして読んでいます。
参照URL：
https://www.theverge.com/policy/915237/palantir-manifesto

TechCrunchも、Palantirが西側防衛を掲げつつ、ICEなどとの関係を含めて同社の思想的傾向が注目されていると報じています。
参照URL：
https://techcrunch.com/2026/04/19/palantir-posts-mini-manifesto-denouncing-regressive-and-harmful-cultures/

一方で、保守系メディアや論者の中には、Palantirの主張を「西側社会が現実主義に戻るための宣言」と肯定的に評価する見方もあります。
American Mindは、Palantirのマニフェストを米国の伝統への回帰として論じ、AI兵器、日本とドイツの再軍備、西側の防衛意識を主要論点として整理しています。
参照URL：
https://americanmind.org/salvo/palantirs-manifesto-is-a-return-to-american-tradition/

つまり、このマニフェストは単純に「危険な文書」と断じるだけでは不十分です。

支持する側から見れば、これはAI時代の国家防衛に対する現実主義です。批判する側から見れば、これはテクノロジー企業による軍事・国家・文化への過剰な介入です。

この両面を見なければ、議論の本質を見誤ります。

Palantirの現実の事業とマニフェストはつながっている

この文書が重く見られる最大の理由は、Palantirが実際に軍事・公共領域で大きな存在感を持っているからです。

Reutersは2026年3月、PalantirのMaven AIシステムが米軍の中核的な軍事システムとして採用される見通しであると報じました。
Mavenは、衛星、ドローン、レーダー、センサーなどからの大量データを分析し、脅威の特定などを支援するシステムとされています。
参照URL：
https://www.reuters.com/technology/pentagon-adopt-palantir-ai-as-core-us-military-system-memo-says-2026-03-20/

また、Reutersは2026年5月、ウクライナのゼレンスキー大統領がPalantirのAlex Karp氏と会談し、ウクライナでのAI活用や戦闘データ活用に関する協力が進んでいると報じています。
参照URL：
https://www.reuters.com/world/europe/zelenskiy-meets-palantir-ceo-ukraine-expands-use-ai-war-2026-05-12/

ここで重要なのは、Palantirが「AIと防衛について意見を述べている企業」ではなく、「AIと防衛の現場で実際にシステムを提供している企業」だという点です。

思想と事業が、かなり近い場所にあります。

これは良く言えば、同社の思想とプロダクトに一貫性があるということです。

悪く言えば、企業の政治思想が公共インフラや軍事システムに実装される可能性があるということです。

日本にとっての論点1：防衛DXは避けられないが、依存先は慎重に見るべき

日本でも防衛DX、統合指揮、サイバー防衛、宇宙・衛星データ、ドローン対処、AIによる意思決定支援の重要性は高まっています。

この流れ自体は、もはや避けられないでしょう。

問題は、どの企業のどの思想に基づくシステムを導入するかです。

防衛システムや公共データ基盤は、一度導入すると長期にわたり運用されます。
データ構造、アクセス権限、監査ログ、分析モデル、業務プロセス、判断フローまで、組織の深い部分に入り込みます。

つまり、単なるソフトウェア調達ではありません。

国家の意思決定インフラを、どの設計思想に預けるのか。

この視点が必要です。

日本にとっての論点2：公共データ基盤における「主権」

Palantir型のシステムは、防衛だけでなく、医療、行政、災害対応、警察、移民管理、金融犯罪対策などにも応用されます。

ここで論点になるのが、データ主権です。

日本の公共データをどこに保存するのか。誰がアクセスできるのか。国外企業がどの範囲まで運用に関与するのか。
AIモデルの判断根拠をどこまで説明できるのか。監査権限は日本側に十分あるのか。

こうした点を曖昧にしたまま、「便利だから」「米国で使われているから」「AI対応が早いから」という理由だけで導入すると、後から統治上の問題が発生します。

これはPalantirに限った話ではありません。

Microsoft、Google、Amazon、Oracle、Salesforce、OpenAI、Anthropicなど、海外テック企業のクラウド・AI基盤を日本の公共領域に導入する際にも共通する課題です。

ただしPalantirの場合、防衛・諜報・警察・安全保障との接点が濃いため、より慎重な確認が必要になります。

日本にとっての論点3：「平和主義」を外部から再定義されるリスク

日本の戦後平和主義には、現実の安全保障課題に対応しきれていない面もあるでしょう。

しかし、それは日本国民が国内で議論し、選挙、国会、憲法論議、外交政策、防衛政策を通じて決めるべき問題です。

海外の防衛テック企業が、日本の平和主義をアジアのパワーバランスという文脈で語るとき、日本側はそれを無批判に受け入れるべきではありません。

もちろん、感情的に反発するだけでも不十分です。

必要なのは、次のような冷静な問いです。

  • Palantirは、なぜ日本の平和主義に言及したのか。
  • その主張は、米国の安全保障戦略とどのように結びつくのか。
  • その主張は、Palantir自身の事業機会とどのように重なるのか。
  • 日本は防衛AI・行政AIを自国でどこまで設計・監査・統制できるのか。
  • 日本国内で、AI時代の安全保障について十分に議論できているのか。

このあたりは、まさに「知らないうちに話が進んでいた」では済まされない領域です。

このマニフェストをどう読むべきか

本記事では、このマニフェストを次のように整理します。

これは、AI時代の軍産データ複合体におけるPalantirの自己定義である。

従来の軍産複合体は、戦闘機、艦船、ミサイル、装甲車、レーダーといった物理的な装備品を中心に回っていました。

しかし、AI時代の軍事力はそれだけではありません。

衛星、ドローン、センサー、通信、クラウド、AI、データ統合、意思決定支援、サイバー防衛、標的識別、補給管理。これらすべてがつながったとき、国家の戦闘能力や危機対応能力が決まります。

Palantirは、まさにその中核に立とうとしている企業です。

だからこそ、同社のマニフェストは重要です。

これは「AI企業が何か強いことを言っている」という話ではありません。

AIで国家をどう動かすか、誰がその基盤を握るか、という話です。

日本が今考えるべきこと

この文書を読んで、すぐに結論を出す必要はありません。

「Palantirは危険だ」と即断する必要もありませんし、「Palantirの言う通り日本も軍事AIを急げ」と短絡する必要もありません。

重要なのは、論点を見落とさないことです。

日本はこれから、防衛力強化、AI活用、行政DX、医療データ連携、災害対応システム、サイバー防衛、ドローン対策など、多くの領域で高度なデータ基盤を必要とします。

そのとき、海外企業の技術を使うこと自体は避けられないかもしれません。

しかし、使うならば、調達条件、監査権限、データ主権、説明責任、国内人材育成、ベンダーロックイン回避をセットで考える必要があります。

便利なものを導入するのは良いことです。

ただし、国家の根幹に関わるシステムでは、「便利」は最終判断基準ではありません。

京都の老舗が暖簾を守るように、国家にも守るべき型があります。新しい道具を使うほど、その型を誰が握るのかを確認しなければなりません。

まとめ：日本について語られている以上、冷静に把握しておきたい

Palantirのマニフェストは、強い思想を持った文書です。

そこには、AI時代の防衛、国家、文化、西側社会、Silicon Valleyの責任、そして日本の平和主義に対する見方が含まれています。

この文書に賛成するか、反対するかは人によって異なるでしょう。

ただし、日本について明確に言及されている以上、今後の防衛DX、行政DX、公共データ基盤、AIガバナンスを考えるうえで、内容を把握しておく価値があります。

Palantirが提示しているのは、AI時代における「技術企業と国家の関係」の一つの未来像です。

その未来像を受け入れるのか。修正して使うのか。距離を置くのか。日本独自の道を設計するのか。

その議論を始めるためにも、まずは「日本のことが語られている」と知ることが第一歩です。

参照URL一覧

AI時代のキャリア戦略

by 塚井海地

Claude Code・Codex時代に伸ばすべき能力と学び方——開発者・要件定義・テスター・PM・情シス向け実践ガイド

Claude Code、Codex、GitHub CopilotのようなAI開発支援ツールが普及し始めたことで、
ソフトウェア開発の現場では「コードを書く力」だけでなく、
「何を作るべきかを定義する力」「AIが作ったものを検証する力」「リスクを判断する力」が重要になりつつあります。

本記事で得られる3つのポイント

  • AI時代に、開発者・要件定義担当・テスター・PM/PL・情シス/発注者が伸ばすべき能力が分かる
  • 能力を伸ばすための具体的な学習方法、実務演習、成果物の作り方が分かる
  • 公式情報・標準・書籍をもとに、年代を問わず学び直すためのロードマップが分かる

なぜ重要か：
AIが実装作業を支援する時代ほど、人間側には「正しく依頼し、正しく検証し、責任を持って判断する力」が求められるためです。

1. AI時代に求められる人材像はどう変わるのか

これまでのIT人材は、プログラミングスキルや開発経験が大きな評価軸でした。
もちろん、今後もコードを理解する力は重要です。
しかし、Claude CodeやCodexのようなAI開発エージェントが普及すると、
単純な実装作業の一部はAIに任せられるようになります。

その結果、人間側に求められる役割は、単なる作業者から、
要件を整理する人、設計を判断する人、品質を保証する人、リスクを管理する人へ移っていくと考えられます。

AnthropicのClaude Code公式ドキュメントでは、Claude Codeはコードベースを読み、ファイル編集、コマンド実行、開発ツール連携を行う
agentic coding tool として説明されています。
また、OpenAIのCodexは、開発者向けのAIコーディングエージェントとして案内されています。
GitHub Copilotも、単なるコード補完だけでなく、AIペアプログラミング、エージェント的な支援へ拡張されています。

2. 全職種共通で押さえるべき考え方

AI時代のスキルアップでは、流行ツールの操作だけを追いかけるのは危険です。
ツールは変わりますが、要件定義、品質保証、セキュリティ、プロジェクト管理、データ管理の基本は簡単には変わりません。

まず押さえるべきは、公式標準や公的資料です。
特に日本国内では、IPAのデジタルスキル標準が重要な基礎資料になります。
デジタルスキル標準は、DXリテラシー標準とDX推進スキル標準で構成され、
すべてのビジネスパーソンとDX推進人材の双方に向けたスキル体系として整理されています。

3. 職種別に伸ばすべき能力

人材タイプ 伸ばすべき能力 なぜ必要か
開発者 AI指示、コードレビュー、アーキテクチャ、セキュリティ、テスト設計 AIが生成したコードを正しく評価し、安全にシステムへ組み込むため
要件定義担当 業務分析、受入基準、非機能要件、データ設計、合意形成 AIや開発者が迷わず実装できる粒度まで要求を整理するため
テスター 探索的テスト、リスクベーステスト、AI出力検証、セキュリティ観点 AI生成物の抜け漏れ、誤実装、業務上の危険箇所を見抜くため
PM/PL AI開発プロセス設計、品質ゲート、コスト管理、説明責任 AI活用による速度向上と品質・責任のバランスを取るため
情シス・発注者 ベンダー成果物の検証、AI利用条件、契約・監査・データ管理 外部委託やAI活用時の責任範囲、品質、情報管理を担保するため

4. 開発者が能力を伸ばす方法

開発者は、AIにコードを書かせるだけでなく、
AIに正しく指示し、生成されたコードをレビューし、設計・セキュリティ・テストの観点で評価できる必要があります。

具体的には、小さなアプリケーションや既存コードを使い、
AIにバグ修正、テスト追加、リファクタリング、セキュリティ改善を依頼します。
その後、必ず差分レビューを行い、なぜその修正が妥当なのか、どのようなリスクがあるのかを記録します。

開発者向けの実践課題

  • Claude CodeやCodexに小さな機能追加を依頼する
  • AIが変更したファイル差分を1行ずつ確認する
  • テストが不足している箇所を自分で洗い出す
  • OWASP ASVSやNIST SSDFを参考に、セキュリティ観点を追加する
  • AIにレビューさせた後、最終判断は自分で行う

開発者におすすめの書籍・資料

書籍・資料 伸ばせる能力 参照URL
Clean Architecture アーキテクチャ設計、依存関係設計 https://www.informit.com/store/clean-architecture-a-craftsmans-guide-to-software-structure-9780134494326
Refactoring 2nd Edition 既存コード改善、レビュー力 https://martinfowler.com/books/refactoring.html
Designing Data-Intensive Applications データ設計、信頼性、拡張性 https://dataintensive.net/
NIST Secure Software Development Framework セキュア開発、サプライヤー管理 https://csrc.nist.gov/pubs/sp/800/218/final
OWASP ASVS Webアプリケーションのセキュリティ検証 https://owasp.org/www-project-application-security-verification-standard/

5. 要件定義担当が能力を伸ばす方法

要件定義担当は、AI時代に最も価値が高まりやすい役割の一つです。
なぜなら、AIは曖昧な要求からでも、それらしい成果物を作ってしまうからです。
要件が曖昧であれば、AIは曖昧なまま高速に実装します。

重要なのは、業務を「人」「データ」「判断」「例外」「制約」に分解し、
AIや開発者が実装可能な粒度まで整理することです。

要件定義担当向けの実践課題

  • 身近な業務を1つ選び、業務フロー図を作成する
  • 登場人物、入力情報、出力情報、判断条件を整理する
  • ユーザーストーリーを作成する
  • Given / When / Then形式で受入基準を書く
  • 性能、可用性、セキュリティ、監査ログなどの非機能要件を追加する

要件定義担当におすすめの書籍・資料

書籍・資料 伸ばせる能力 参照URL
IREB CPRE Foundation Level 要求工学、要求定義、要求管理 https://cpre.ireb.org/en/concept/foundationlevel
BABOK Guide ビジネス分析、業務分析 https://www.iiba.org/career-resources/a-business-analysis-professionals-foundation-for-success/babok/
Software Requirements, 3rd Edition 要求開発、要求管理 https://www.microsoftpressstore.com/store/software-requirements-9780735679665
要求工学知識体系 REBOK 日本の開発現場に近い要求定義 https://www.kindaikagaku.co.jp/book_list/detail/9784764904040/

6. テスターが能力を伸ばす方法

テスターは、単純な手順実行者ではなく、品質リスクを見抜く専門職へ移行していく必要があります。
AIはテストケースを大量に作成できますが、
「そのテストで本当に重要なリスクを確認できているか」は人間が判断する必要があります。

特に、探索的テスト、リスクベーステスト、AI生成テストの検証、セキュリティ観点は重要です。
AIが出したテストケースをそのまま採用するのではなく、
業務影響、権限、データ整合性、例外処理、監査ログまで確認する必要があります。

テスター向けの実践課題

  • AIにテストケースを作らせる
  • 自分で不足している観点を追加する
  • リスクマトリクスを作成する
  • 探索的テストチャーターを作成する
  • バグ報告テンプレートを整備する

テスターにおすすめの書籍・資料

書籍・資料 伸ばせる能力 参照URL
ISTQB Certified Tester Foundation Level v4.0 ソフトウェアテストの基礎体系 https://istqb.org/certifications/certified-tester-foundation-level-ctfl-v4-0/
JSTQB Foundation Level シラバス 日本語で学べるテスト標準 https://jstqb.jp/syllabus.html
The Art of Software Testing テストの基本思想 https://dl.acm.org/doi/10.5555/2161638
ソフトウェアテスト技法ドリル 第2版 テスト設計、実践演習 https://www.juse-p.co.jp/products/view/934
SQuBOK Guide V3 ソフトウェア品質体系 https://www.juse.or.jp/sqip/squbok/

7. PM/PLが能力を伸ばす方法

PM/PLは、AI時代に「進捗管理者」だけでは足りません。
AIをどの工程で使うのか、どこから人間のレビューを必須にするのか、
どの品質ゲートを通過しなければリリースできないのかを設計する必要があります。

AI開発を安全に運用するには、AI利用ルール、Definition of Done、レビュー基準、RACI表、
コスト管理表、監査ログ設計が必要になります。

PM/PL向けの実践課題

  • AI利用ポリシーを作成する
  • AI生成物のレビュー基準を定義する
  • Definition of Doneを整備する
  • 品質ゲートを設計する
  • AI利用料、レビュー工数、手戻り工数を管理する

PM/PLにおすすめの書籍・資料

書籍・資料 伸ばせる能力 参照URL
PMBOK Guide プロジェクトマネジメント体系 https://www.pmi.org/standards/pmbok
Scrum Guide アジャイル開発、スクラム運営 https://scrumguides.org/
Accelerate DevOps、DORA指標、開発生産性 https://itrevolution.com/product/accelerate/
Continuous Delivery CI/CD、リリース品質 https://martinfowler.com/books/continuousDelivery.html
Team Topologies チーム設計、認知負荷、組織設計 https://teamtopologies.com/book

8. 情シス・発注者が能力を伸ばす方法

情シスや発注者は、AI時代に非常に重要な立場になります。
なぜなら、AIを活用した開発では、ベンダーがどのAIを使い、
どの情報を入力し、どの成果物をAIで作成し、誰が検証したのかを確認する必要があるからです。

特に、AI利用条件、機密情報の取り扱い、生成コードの責任範囲、著作権・ライセンス確認、
セキュリティ要求、監査証跡は、発注側が理解しておくべき領域です。

情シス・発注者向けの実践課題

  • AI利用条件付きRFPを作成する
  • 納品物チェックリストを整備する
  • セキュリティ要求一覧を作成する
  • データ管理台帳を作る
  • AI利用の監査証跡テンプレートを作る

情シス・発注者におすすめの書籍・資料

書籍・資料 伸ばせる能力 参照URL
NIST Cybersecurity Framework 2.0 サイバーリスク管理 https://www.nist.gov/cyberframework
NIST AI Risk Management Framework AIリスク管理 https://www.nist.gov/itl/ai-risk-management-framework
OWASP Top 10 for LLM Applications 生成AI特有のセキュリティリスク https://owasp.org/www-project-top-10-for-large-language-model-applications/
DAMA-DMBOK データ管理、データガバナンス https://dama.org/learning-resources/dama-data-management-body-of-knowledge-dmbok/
個人情報保護委員会 個人情報保護、法令確認 https://www.ppc.go.jp/

9. 年代を問わず使える学習ロードマップ

AI時代の学び直しに、年齢は大きな制約ではありません。
むしろ、業務経験、失敗経験、調整経験、品質へのこだわりがある人ほど、
AIを実務に活かしやすい可能性があります。

重要なのは、書籍や公式資料を読むだけで終わらせず、
実際に成果物を作り、AIや人間からレビューを受け、改善することです。

学習ステップ

段階 やること 成果物
第1段階 公式標準を確認する 学習テーマ一覧、参照URLリスト
第2段階 書籍で体系を学ぶ 読書メモ、用語集、チェックリスト
第3段階 AIを使って成果物を作る 要件定義書、テスト観点表、レビュー記録
第4段階 AIと人間のレビューを受ける 改善履歴、指摘一覧、再レビュー結果
第5段階 小さく業務に適用する 社内テンプレート、運用ルール、事例メモ

10. 90日間の実践プラン

人材タイプ 1〜30日 31〜60日 61〜90日
開発者 AIで小さな修正を行い、差分レビューする テスト追加、リファクタリング、脆弱性修正を試す AI利用時のレビュー観点表を作る
要件定義担当 身近な業務を業務フローに分解する ユーザーストーリーと受入基準を作る 非機能要件とデータ定義を追加する
テスター ISTQB/JSTQBの基本用語を押さえる AI生成テストケースをレビューする リスクベーステスト表と探索的テストチャーターを作る
PM/PL AI利用工程と禁止事項を整理する 品質ゲートとDefinition of Doneを作る コスト管理表と監査ログ設計を作る
情シス・発注者 AI利用条件と機密情報の扱いを整理する RFPと納品物チェックリストを作る ベンダー比較表と監査証跡テンプレートを作る

11. まとめ：AI時代に強いのは、AIを疑いながら使える人

AI時代に強い人材とは、単にAIツールを使える人ではありません。
AIに何を任せ、何を任せてはいけないかを判断できる人です。

開発者であれば、AI生成コードをレビューできること。
要件定義担当であれば、AIが迷わない要求へ落とし込めること。
テスターであれば、AIが見落とすリスクを発見できること。
PM/PLであれば、AI活用を前提に品質と責任を設計できること。
情シス・発注者であれば、AI利用条件、契約、監査、データ管理を判断できること。
これらが今後の実務価値になります。

実装だけをAIに任せる時代になるほど、
人間には「要件」「品質」「責任」「説明」の力が求められます。
逆に言えば、これらを鍛えれば、年代を問わずAI時代でも十分に価値を発揮できます。

最後に押さえておきたいのは、AIは万能の代替者ではなく、使い方によって成果を増幅する道具だという点です。
良い要件、良い設計、良いテスト、良いレビューがあってこそ、AIは力を発揮します。
そこを整える人材こそ、これからの現場で最も頼りにされる存在になるはずです。

AIセキュリティ展望 ミュトス後に起こること

by 塚井海地

ミュトス後に起こること

AnthropicのClaude Mythos Previewが表に出てきたことは、単なる新型AIモデルの話ではありません。
サイバーセキュリティの世界において、脆弱性探索、コード解析、攻撃経路の検証、修正方針の提示といった領域が、AIによって大きく加速し始めたことを示す象徴的な出来事です。

本記事では、Claude Mythos Previewの登場を起点に、今後起こる可能性が高い変化を、セキュリティコンサルタント、セキュリティ研究者、企業のリスク管理担当者の視点から深く考察します。
なお、本記事は攻撃手法の解説ではなく、防御・運用・リスク管理を目的とした分析です。

本記事で得られる3つのポイント

  • ミュトスの登場は、脆弱性探索のAI化が公然化した転換点である。
  • 今後はゼロデイそのものよりも、発見・悪用・修正・公開までの時間差をめぐる競争が激化する。
  • 企業も個人も、月次更新や人手中心のセキュリティ運用から、常時監視・常時更新・常時検証の考え方へ移行する必要がある。

なぜ重要か：
AIによってサイバー攻撃と防御の速度が上がると、従来の「そのうち更新する」「問題が起きたら対応する」という考え方では、攻撃側のスピードに追いつけなくなるためです。

ミュトスが示した本質は「AIが脆弱性を探せる時代」の到来である

Anthropicは、Claude Mythos PreviewをProject Glasswingの中核として位置づけています。
公式説明では、Claude Mythos PreviewはAnthropicの汎用フロンティアモデルであり、コーディング能力とエージェント的タスク能力に優れるモデルとされています。
そして、その能力の延長線上として、複雑なソフトウェアを理解し、修正し、脆弱性を見つける能力も高いと説明されています。

参照URL：
https://www.anthropic.com/project/glasswing

AnthropicのRed Teamによる解説でも、Claude Mythos Previewはコンピューターセキュリティタスクにおいて極めて高い能力を示すモデルとして説明されています。
ここで重要なのは、Mythosが「ハッキング専用AI」としてではなく、汎用AIの高度化によってサイバー能力も高まったモデルとして語られている点です。

参照URL：
https://red.anthropic.com/2026/mythos-preview/

これは非常に大きな意味を持ちます。
つまり、今後出てくる類似ツールは、必ずしも「攻撃AI」「脆弱性探索AI」という名前で登場するとは限りません。
むしろ、AIコードレビュー、AIセキュア開発支援、AIペネトレーションテスト支援、AI SOC支援、AI DevSecOpsエージェントといった、正当な防御・開発支援ツールの形で広がっていく可能性が高いと考えられます。

予想1：ゼロデイ市場は「職人技」から「処理能力勝負」へ変わる

従来、ゼロデイ脆弱性の発見は、高度な専門知識、長年の経験、対象ソフトウェアへの深い理解を必要とする職人技に近い領域でした。
OS、ブラウザ、画像処理ライブラリ、動画コーデック、PDFリーダー、VPN機器、ルーター、業務アプリなどを解析し、クラッシュや不正挙動を見つけ、再現条件を絞り込み、悪用可能性を評価するには、相当な技術力が必要でした。

しかし、Mythos級のAIが登場したことで、脆弱性探索は人間だけが行う高度技能から、AIと解析ツールを組み合わせた探索パイプラインへ変わっていく可能性があります。

従来の脆弱性探索 AI時代の脆弱性探索
専門家がコードを読む AIがコード全体を要約し、危険箇所を候補化する
人間が手作業で検証する AIが再現手順やテストケースを提案する
限られた範囲を深く見る 広い範囲を高速にスクリーニングする
発見までに長時間かかる 仮説生成と一次評価が高速化する
修正方針は別途検討する AIが修正案や影響範囲まで提示する

もちろん、AIが出す結果には誤検知、再現不能、環境依存、理論上の問題も含まれます。
しかし、探索の母数が増えれば、有効な脆弱性が見つかる確率も上がります。
今後は「誰が最初に見つけるか」だけでなく、「誰が最も広く、速く、継続的に探索できるか」が競争軸になります。

予想2：脆弱性報告の洪水が起きる

AIによる脆弱性探索が普及すると、ソフトウェアベンダー、OSSプロジェクト、クラウド事業者、SaaS企業には、AIで生成された脆弱性報告が大量に届くようになるでしょう。
その中には有益な報告もありますが、再現不能なもの、既知問題の焼き直し、低リスク問題の大量報告、AI生成のもっともらしい長文レポートも増えると考えられます。

増える可能性がある報告 ベンダー側の課題
再現不能な脆弱性報告 トリアージ工数を消耗する
低リスク問題の大量報告 本当に危険な問題が埋もれる
AI生成の長文レポート 一見もっともらしく、精査に時間がかかる
バグバウンティ目的の粗い報告 報奨金制度の運用負荷が増える
攻撃者による探り 修正前情報を引き出される可能性がある

これから重要になるのは、脆弱性を見つける能力だけではありません。
むしろ、見つかった脆弱性を正しく評価し、優先順位を付け、影響範囲を判断し、修正し、公開する能力が問われます。

CISAは、実際に悪用が確認された脆弱性をまとめるKnown Exploited Vulnerabilities Catalogを公開しています。
今後の脆弱性管理では、単にCVSSスコアを見るだけでなく、実際に悪用されているかどうか、外部公開資産に影響するか、修正可能か、といった観点がさらに重要になります。

参照URL：
https://www.cisa.gov/known-exploited-vulnerabilities-catalog

予想3：攻撃者はモデルそのものよりもワークフローを真似る

多くの人は「Claude Mythos Previewが一般公開されるかどうか」に注目します。
しかし、攻撃者や研究者の実務目線では、より重要なのはMythosそのものではなく、Mythosが実現したワークフローです。

完全に同じモデルがなくても、既存のAI、静的解析ツール、ファザー、シンボリック実行、コンテナ環境、CI/CD、エージェント基盤を組み合わせれば、一定レベルの自動解析パイプラインは構築できます。

構成要素 役割
高性能LLM コード理解、仮説立案、修正案生成
静的解析ツール 危険な関数や実装パターンを検出
ファザー 大量の入力を生成し、不正挙動を探す
パッチ差分解析 修正前後の差分から弱点を推定する
コンテナ環境 再現テストを隔離環境で実行する
エージェント基盤 長時間タスクを分解し、再試行する

攻撃者にとって、Mythosと同等の能力は必ずしも必要ありません。
既知脆弱性の悪用準備を自動化する、パッチ差分から未更新環境を狙う、設定ミスを大量探索する、フィッシング文面を高度化する、といった用途であれば、より低い性能のAIでも十分に悪用価値があります。

つまり今後問題になるのは、単体の超高性能AIだけではありません。
そこそこ優秀なAIを、多数のツールと組み合わせて、反復的に回す攻撃ワークフローです。

予想4：パッチ公開直後が最も危険な時間帯になる

ソフトウェアの修正パッチは、防御側にとっては安全性を高める情報です。
一方で、攻撃者にとっては「どこが直されたのか」を知るためのヒントにもなります。

AIがパッチ差分を読み、修正意図を推定し、攻撃可能性を評価できるようになると、パッチ公開後から悪用準備までの時間は短くなる可能性があります。
これは、すでに修正情報が出ているにもかかわらず、まだ更新していない環境を狙うNデイ攻撃の危険性を高めます。

対象 特に更新を急ぐべき理由
ブラウザ Webアクセスだけで攻撃面になりやすい
スマホOS 本人確認、決済、MFAが集約されている
VPN機器 社内ネットワークへの入口になる
ルーター 家庭や中小企業の境界に位置する
WordPress 自動攻撃の対象になりやすい
PDF・Office関連 添付ファイル攻撃に使われやすい
画像・動画処理ライブラリ メディアファイル経由の攻撃対象になり得る

これからは、「月に一度まとめて更新する」という運用だけでは不十分な場面が増えます。
悪用中の脆弱性、外部公開システム、認証基盤、ブラウザ、VPN、ルーター、CMSについては、より短い対応サイクルを設定する必要があります。

予想5：防御側もAI化し、人間だけのSOCは限界に近づく

企業のセキュリティ運用では、SOC、SIEM、EDR、XDRといった仕組みが使われています。
しかし、アラート量はすでに多く、誤検知も少なくありません。
AIによる攻撃自動化が進めば、人間だけでログを読み、アラートを分類し、影響範囲を判断する運用はさらに厳しくなります。

従来のSOC 今後のSOC
アラートを人間が読む AIが要約・分類する
手動でログを追う AIが時系列を構成する
手動で影響範囲を調査する AIが関連端末・ユーザーを抽出する
対応手順を人間が探す AIが推奨アクションを提示する
月次レポート中心 リアルタイムのリスク評価へ移行する

ただし、完全自動化には危険もあります。
誤って重要システムを停止したり、攻撃者にAIの応答パターンを学習されたりする可能性があるためです。
現実的には、ログ要約、アラート分類、影響範囲の候補抽出はAIが担い、重要サーバー停止、顧客通知、法務判断、経営判断は人間が責任を持つ形になるでしょう。

予想6：セキュリティ製品の「AI対応」は急増するが、実力差が大きく出る

Mythosのような話題が出ると、セキュリティ製品市場では「AI対応」「AI防御」「AI SOC」「AIペンテスト」といった言葉が一気に増えます。
しかし、単にAIチャット機能を付けただけの製品と、本当に防御力を高める製品はまったく別物です。

評価ポイント 見るべき理由
資産情報と連携できるか 守る対象が分からなければ意味がない
ログの時系列を正しく構成できるか 誤判断を防ぐために重要
脆弱性と実際の露出を結びつけられるか 優先順位付けに必須
誤検知を減らせるか 運用疲れを防ぐ
自動修復まで到達できるか 実効性が高い
説明責任を持てるか 監査、法務、経営報告で重要

今後のセキュリティ製品に求められるのは、「危険です」と表示することではありません。
何を、どの順番で、誰が、いつまでに直すべきかまで業務プロセスへ落とし込めることです。

予想7：ソフトウェア開発は「作る」から「常時検証する」へ変わる

AIによるコード生成は、開発速度を大きく引き上げます。
一方で、AIが生成したコードにも脆弱性や設計上の問題が含まれる可能性があります。
したがって、AI時代の開発では、コードを書く速度よりも、生成されたコードをどう検証し、どう継続的に安全性を確認するかが重要になります。

NISTはSecure Software Development Framework、いわゆるSSDFを通じて、セキュアなソフトウェア開発の基本的な実践を整理しています。
AI時代には、こうしたセキュア開発プロセスをAIツールと組み合わせて、開発ライフサイクルに組み込むことが求められます。

参照URL：
https://csrc.nist.gov/projects/ssdf

重要スキル 内容
セキュア設計 認証、認可、権限分離を設計できる
脅威モデリング どこが攻撃されるかを事前に想定する
レビュー設計 AIレビューと人間レビューを組み合わせる
テスト設計 正常系だけでなく異常系を検証する
依存関係管理 OSSライブラリとバージョンを把握する
秘密情報管理 APIキーやトークンを漏らさない
CI/CD統制 自動検査を開発工程に組み込む

予想8：SBOMとサプライチェーン管理の重要性がさらに高まる

AIが脆弱性を高速に見つける時代には、自社がどのソフトウェア、どのライブラリ、どのOSS部品に依存しているかを把握できていないこと自体がリスクになります。
そこで重要になるのがSBOM、つまりSoftware Bill of Materialsです。

CISAは、SBOMをソフトウェアコンポーネントの「材料表」のようなものとして説明しています。
これは、ソフトウェアに含まれる部品や依存関係を可視化するための考え方です。

参照URL：
https://www.cisa.gov/sbom

SBOMが重要になる理由 実務上の意味
影響範囲を早く判断できる 脆弱なライブラリを使っているか確認しやすい
ベンダー依存を可視化できる 外部委託やSaaS利用時のリスクを把握しやすい
更新優先度を決めやすい 重要システムから対応できる
監査対応に使える 説明責任を果たしやすい
AI診断と相性が良い AIが依存関係と脆弱性情報を突合しやすい

これからの企業セキュリティでは、「脆弱性が出たかどうか」よりも、「その脆弱性が自社のどこに関係しているかを即答できるか」が問われます。

予想9：金融・重要インフラ・政府機関は早く動く

Reutersは、日本の金融当局がAnthropicの高度なMythos AIモデルに関する問題を協議するため、国内の大手金融機関と会合を行うと報じています。
金融分野は、リアルタイム性、相互接続性、信頼性、古いシステムの残存、金銭的動機の強い攻撃者という複数のリスク要因を抱えているため、AI時代のサイバーリスクに敏感に反応するのは自然です。

参照URL：
https://www.reuters.com/world/asia-pacific/japan-finance-minister-meet-banks-discuss-mythos-ai-model-bloomberg-news-reports-2026-04-22/

また、ReutersはMicrosoftがAnthropicのMythosを自社のセキュリティ開発プログラムへ統合する方針についても報じています。
これは、防御側の大手テクノロジー企業が、AIをセキュリティ開発工程に組み込み始めていることを示す動きとして注目できます。

参照URL：
https://www.reuters.com/technology/microsoft-integrate-anthropics-mythos-into-its-security-development-program-2026-04-22/

領域 起こりそうな変化
金融 AI時代のサイバー演習、脆弱性管理、委託先管理が強化される
重要インフラ 脆弱性報告、パッチSLA、復旧訓練が厳格化される
ソフトウェア調達 SBOM提出やセキュア開発プロセスの確認が増える
クラウド利用 第三者リスク管理と監査が強化される
サイバー保険 MFA、EDR、バックアップ、パッチ運用の審査が厳しくなる

予想10：一般ユーザー向け攻撃は、より自然で、より個別化される

Mythosそのものは高度なサイバー能力に関する話ですが、AIの進化は一般ユーザー向けの攻撃にも波及します。
特に、フィッシングメール、SMS詐欺、SNSのDM詐欺、偽サポート、投資詐欺、偽アプリなどは、今後さらに自然で個別化されたものになるでしょう。

攻撃 今後の変化
フィッシングメール 日本語が自然になり、業務文面に近づく
SMS詐欺 宅配、銀行、税金、決済を装う文面が巧妙化する
SNS詐欺 投稿履歴や興味関心に合わせたDMが増える
偽サポート AI音声やAIチャットで自然に誘導する
投資詐欺 個人の関心や属性に合わせた勧誘が増える
偽アプリ 説明文やレビューまで本物らしく作られる

これからは、「文章が自然だから本物」と判断するのは危険です。
判断基準は文章の自然さではなく、操作の経路です。
メールやSMSのリンクからログインするのではなく、自分で公式アプリや公式サイトを開いて確認する習慣が重要になります。

予想11：ブラウザ・OS・スマホは、より強制更新寄りになる

AIによって脆弱性悪用までの時間が短くなると、OSやブラウザのベンダーは、より強い更新モデルへ移行していく可能性があります。
ユーザー任せの更新では、攻撃側の速度に追いつけない場面が増えるためです。

領域 予想される変化
ブラウザ セキュリティ更新の自動適用がさらに強化される
スマホOS 古いOSへの警告やサポート期限表示が強化される
アプリストア 危険権限アプリや不審な開発者への審査が厳しくなる
企業端末 MDMによる強制更新が一般化する
ルーター・IoT 自動更新対応機種への移行圧力が高まる

個人ユーザーにとっては、古いスマホ、古いPC、古いルーター、更新されていないNASやWebカメラを使い続けるリスクが、これまで以上に大きくなります。

予想12：発見能力よりも復旧能力が価値になる

セキュリティの成熟した組織ほど、「侵入されない」ことだけに依存しません。
侵入されても被害を限定し、早く検知し、確実に復旧することを重視します。
Mythos級の能力が広がると、この考え方はさらに重要になります。

能力 意味
資産把握 何を持っているか分かる
露出管理 どこが外部から見えるか分かる
権限管理 侵入されても横展開されにくい
ログ管理 何が起きたか追える
バックアップ 暗号化や破壊を受けても戻せる
復旧訓練 机上の計画ではなく実際に復元できる
連絡体制 被害時に迷わず動ける

個人でも同じです。
メールアカウントを失ったときの復旧手段、2FA復旧コード、写真や動画のバックアップ、SNS乗っ取り時の対応、WordPress改ざん時の復元手順を持っているかどうかが重要になります。

近未来シナリオ：今後の流れを時系列で読む

0〜6か月：情報収集と市場過熱

起こること 内容
AIセキュリティ製品の発表増加 各社がAI防御、AI SOC、AI診断を打ち出す
政府・金融機関の警戒強化 ガイドライン、演習、タスクフォースが増える
OSS側の対応ルール整備 AI生成報告の受け入れ基準が議論される
企業の棚卸し需要増加 資産管理、SBOM、脆弱性管理への関心が高まる

6〜18か月：AI脆弱性探索の実務導入

起こること 内容
大企業でAIセキュリティ検証が標準化 開発工程、SOC、脆弱性管理に組み込まれる
バグバウンティ規約が変わる AI生成報告の扱いが明文化される
セキュリティ人材像が変わる AIを使える分析者、レビューできる専門家が重視される
監査項目が増える SBOM、ログ、復旧訓練、パッチSLAが問われる

18〜36か月：攻防の標準装備になる

起こること 内容
AIコードレビューが標準化 人間レビューだけでは不十分と見なされる
AIペンテストが一般化 定期診断の速度と範囲が変わる
自動修復が広がる パッチ提案や設定修正が自動化される
攻撃者もAI化する フィッシング、Nデイ攻撃、探索が高速化する
古いCMSや端末が危険化する サポート切れ利用が大きなリスクになる

企業・個人事業主が今すぐ準備すべきこと

1. 資産台帳を作る

最初にやるべきことは、AIツールの導入ではありません。
まず、自社または自分が何を持っているかを把握することです。

管理対象 例
PC Windows、macOS端末
スマホ iPhone、Android端末
サーバー Web、DB、NAS、VPS
SaaS Google Workspace、Microsoft 365、Slackなど
Webサイト WordPress、ECサイト、LP
ドメイン DNS、メール設定、証明書
アカウント 管理者、共同編集者、外部委託先
OSS ライブラリ、テーマ、プラグイン

2. 重要度を分ける

重要度 対象
最重要 メール、金融、管理者アカウント、顧客情報
高 Webサイト、クラウドストレージ、SNS、業務SaaS
中 業務PC、制作データ、社内資料
低 一時ファイル、公開済み資料、検証環境

3. 更新SLAを決める

深刻度 対応目安
悪用中 即日〜72時間以内
Critical 1週間以内
High 2週間以内
Medium 月次対応
Low 定例対応

4. 例外管理を作る

古いシステムや、すぐに更新できないシステムは必ず出ます。
重要なのは放置ではなく、例外として管理することです。

例外項目 管理内容
更新できない理由 業務影響、互換性、ベンダー制約など
代替策 ネットワーク分離、WAF、アクセス制限など
期限 いつまで許容するか
責任者 誰がリスクを承認しているか
見直し周期 月次または四半期ごとに確認する

5. 復旧訓練をする

バックアップは、取るだけでは不十分です。
実際に戻せるかを確認して初めて、復旧能力になります。

対象 確認事項
WordPress データベースと画像を復元できるか
PC 重要ファイルを別端末で開けるか
スマホ 機種変更時に復元できるか
SaaS 管理者アカウントを復旧できるか
2FA 復旧コードが使えるか

最終考察：ミュトスは警鐘ではなく予告編である

Claude Mythos Previewが示したものは、単なる新モデルの性能ではありません。
サイバー攻撃と防御の世界で、人間の時間感覚がAIの時間感覚に置き換わり始めたということです。

これまでは、人間が探し、人間が試し、人間が直していました。
これからは、AIが探し、AIが仮説を出し、AIが試し、AIが修正案を提示します。
その結果、人間の役割は、手作業の実行者から、AIの探索範囲を設計し、出力を検証し、重要判断を下す監督者へ変わっていきます。

これまでの人間の役割 これからの人間の役割
手作業で脆弱性を探す AI探索の範囲と条件を設計する
ログを一つずつ読む AIの分析結果を検証する
すべてを自分で判断する 重要判断に集中する
パッチを待つ 暫定緩和策と優先順位を決める
事故後に慌てて対応する 事故前提で復旧計画を持つ

今後、Mythosに近いツールや、これを凌駕するツールは出てくるでしょう。
ただし、それは突然「攻撃AI」という名前で出てくるとは限りません。
まずはコードレビュー、脆弱性診断、SOC支援、バグバウンティ、ペンテスト支援、DevSecOpsという、まっとうな顔で広がっていくはずです。

そして、その裏側で攻撃者も同じ発想を使います。
だからこそ、今やるべきことは恐怖に飲まれることではありません。
資産を把握し、更新を早め、権限を絞り、ログを見て、バックアップから復旧できる状態を作ることです。

AI時代のセキュリティは、派手な新兵器の話に見えて、最後はかなり地味です。
台帳、更新、権限、ログ、バックアップ。
まるで昔ながらの帳簿管理のようですが、こういう基礎を丁寧にやる組織と個人が、結局いちばん強いのです。

参照URL

AI時代の個人セキュリティ実践ガイド

by 塚井海地

PC・スマホ利用で気をつけること

Claude Mythos Previewのような高度なAIモデルが表に出てきたことで、サイバーセキュリティの前提は大きく変わり始めています。
これまで専門家が時間をかけて行っていた脆弱性探索、コード解析、攻撃経路の検証といった作業が、AIによって高速化される可能性が高まっているためです。

本記事では、セキュリティコンサルタントやセキュリティ研究者の視点を踏まえながら、一般ネットユーザーがPCやスマホを使う際に、これから何を意識すべきかを実践的に整理します。

本記事で得られる3つのポイント

  • AI時代には、個人ユーザーも「狙われる前提」でPC・スマホを使う必要がある。
  • 最重要対策は、パスワード、MFA、パスキー、OS更新、バックアップの見直しである。
  • 今後は「文章が自然だから本物」と判断せず、公式アプリ・公式サイトから確認する習慣が重要になる。

なぜ重要か：
AIによって攻撃の探索速度が上がると、古い端末、未更新アプリ、使い回しパスワード、安易なSMSリンク操作といった日常の小さな油断が、これまで以上に大きなリスクへ直結するためです。

AI時代のセキュリティは「自分には関係ない」では済まない

Anthropicは、Claude Mythos PreviewをProject Glasswingの一環として公表しています。
Project Glasswingは、重要ソフトウェアをAI時代に向けて保護する取り組みであり、Claude Mythos Previewはその中核となるフロンティアAIモデルとして位置づけられています。

参照URL：
https://www.anthropic.com/project/glasswing

Anthropicの技術解説では、Mythos Previewが高度なコンピューターセキュリティタスクに非常に強い能力を示し、非専門家でも高度な脆弱性の発見や悪用検証に近づける可能性があることが説明されています。

参照URL：
https://red.anthropic.com/2026/mythos-preview/

ここで重要なのは、Mythosそのものが一般公開されているかどうかだけではありません。
こうした能力が技術的に示された以上、今後は類似するツールやワークフローが、研究機関、企業、国家、攻撃者グループの間で増えていくと考えるのが自然です。

一般ユーザーにとっては、「自分は有名人ではないから大丈夫」という考え方を見直す必要があります。
攻撃者が狙うのは、あなた個人の名前や肩書きだけではありません。
メールアカウント、SNS、決済情報、スマホ内の認証情報、クラウドストレージ、ブラウザに保存されたCookieなどが狙われます。

攻撃者は「あなた個人」ではなく「使える入口」を探している

一般ユーザーが誤解しやすいのは、「自分には盗まれて困る情報はない」という考え方です。
しかし、攻撃者から見れば、一般ユーザーのPCやスマホは十分に価値があります。

狙われるもの 悪用例
メールアカウント パスワードリセット、なりすまし、詐欺メール送信
SNSアカウント 乗っ取り、投資詐欺、知人へのDM詐欺
スマホ本体 認証コード受信、決済アプリ悪用、本人確認の突破
クラウドストレージ 写真、仕事資料、個人情報の流出
ブラウザ保存情報 ログイン状態の奪取、Cookie窃取
WordPress管理画面 サイト改ざん、SEOスパム、フィッシングページ設置

現代のスマホは、財布、鍵、身分証、通帳、連絡網、本人確認装置をまとめた端末です。
落とすと痛いどころではなく、人生の操作権限を少し持っていかれる可能性があります。

これからの基本姿勢は「簡易版ゼロトラスト」である

企業セキュリティでは、ゼロトラストという考え方が一般化しています。
これは「社内だから安全」「一度ログインしたから安全」とは考えず、常に確認し続ける設計思想です。

一般ユーザーも、PCやスマホの操作において、簡易版ゼロトラストを取り入れるべきです。

従来の感覚 これからの感覚
有名企業のロゴがあるから大丈夫 URL、送信元、アプリ権限を確認する
自然な日本語だから本物 AIで自然な詐欺文面は作れると考える
SMS認証があるから安心 SMSは補助的な防御と考える
ウイルス対策ソフトを入れているから大丈夫 更新、認証、権限、バックアップまで含めて守る
スマホはPCより安全 スマホは本人確認の中核なので最重要資産と考える

最重要対策1：パスワードからパスキーへ移行する

AI時代において、最も危険なのは弱いパスワードそのものよりも、パスワードの使い回しです。
一つのサービスから漏れたIDとパスワードが、別のサービスに自動で試される攻撃は、今後さらに効率化される可能性があります。

FIDO Allianceは、パスキーをパスワードに代わる認証技術として説明しており、パスキーはフィッシング耐性を持ち、パスワードの盗難や使い回しに起因するリスクを減らせるとしています。

参照URL：
https://fidoalliance.org/passkeys/

NCSCも、パスキーは従来のログイン方法より安全性と使いやすさの両面で優れた選択肢であると説明しています。

参照URL：
https://www.ncsc.gov.uk/blogs/passkeys-are-more-secure-than-traditional-ways-to-log-in

優先度 認証方式 評価
最優先 パスキー フィッシング耐性が高く、今後の標準候補
高 物理セキュリティキー 高リスクユーザーや重要アカウントに有効
中 認証アプリによるMFA SMSより望ましい
低 SMS認証 何もないより良いが過信は禁物
危険 パスワードのみ 重要アカウントでは避けるべき

まず見直すべきアカウントは、Google、Apple、Microsoft、メインメール、銀行、証券、暗号資産取引所、Amazonや楽天などのECサイト、SNS、YouTube、WordPress管理画面です。

最重要対策2：多要素認証を重要アカウントで有効化する

NISTは、多要素認証を、ユーザー名とパスワードだけではなく、複数の要素で本人確認を行う重要なセキュリティ強化策として説明しています。

参照URL：
https://www.nist.gov/itl/smallbusinesscyber/guidance-topic/multi-factor-authentication

ただし、多要素認証にも強弱があります。
SMS認証は何も設定していない状態よりは良いものの、今後はパスキー、物理セキュリティキー、認証アプリを優先したいところです。

MFA方式 推奨度 注意点
パスキー 高 対応サービスでは最優先
物理セキュリティキー 高 紛失時に備えて予備キーを用意する
認証アプリ 中〜高 偽サイトにコードを入力しない
プッシュ通知承認 中 身に覚えのない承認通知は拒否する
SMS 中〜低 SIMスワップや転送リスクを意識する
メールコード 中〜低 メールアカウントが乗っ取られると弱い

重要なのは、「認証コードが届いたから安全」ではなく、「自分が正しいサイトやアプリで操作しているか」を確認することです。

最重要対策3：OS・ブラウザ・アプリ更新を後回しにしない

AIによって脆弱性の発見や悪用準備が高速化されると、公開された脆弱性が攻撃に使われるまでの時間も短くなる可能性があります。
そのため、PCやスマホの更新を後回しにする習慣は、今後さらに危険になります。

Googleは、Android端末の設定画面からAndroidバージョン、セキュリティアップデート、Google Playシステムアップデートの状態を確認できると案内しています。

参照URL：
https://support.google.com/android/answer/7680439?hl=en

更新対象 理由
iOS / Android 端末全体の脆弱性修正
Windows / macOS OS権限昇格やブラウザ連携の脆弱性対策
Chrome / Safari / Edge / Firefox Web経由攻撃の入口になりやすい
LINE / WhatsApp / Signal メッセージ経由の攻撃対象になりやすい
PDFリーダー 添付ファイル攻撃に使われやすい
WordPress / プラグイン 個人ブログや小規模サイトへの自動攻撃が多い
ルーター / NAS 家庭内ネットワークの盲点になりやすい

最重要対策4：スマホを「本人確認端末」として守る

今のスマホは、単なる通信端末ではありません。
SMS認証、認証アプリ、メール、決済アプリ、生体認証、写真、連絡先、クラウドストレージへの入口が集約されています。

つまりスマホは、攻撃者から見ると「本人になりすますための端末」です。
PC以上に慎重に扱うべき重要資産と考える必要があります。

スマホ操作 意識すべきこと
アプリを入れる 公式ストアから入れる
権限を許可する 連絡先、写真、位置情報が本当に必要か確認する
QRコードを読む 開いたURLを確認する
SMSリンクを開く 原則としてリンクから直接ログインしない
公共Wi-Fiを使う 金融、証券、管理画面の操作は避ける
端末を売却する 初期化とアカウント解除を確実に行う
古い端末を使う セキュリティ更新が続いているか確認する

最重要対策5：アプリ権限を最小限にする

攻撃者は、必ずしもOS全体を完全に乗っ取る必要はありません。
連絡先、写真、位置情報、マイク、カメラ、通知、クリップボードなどの権限だけでも、悪用価値があります。

権限 悪用された場合のリスク
連絡先 知人への詐欺、スパム拡散
写真 個人情報、位置情報、書類画像の流出
位置情報 行動パターンの把握
マイク 盗聴リスク
カメラ プライバシー侵害
通知 認証コードやDM内容の露出
クリップボード コピーしたパスワードや暗号資産アドレスの窃取
ファイルアクセス 仕事資料、個人ファイルの流出

使っていないアプリは削除し、位置情報や写真へのアクセスは必要最小限にします。
無料アプリは無料ではありません。
代金の代わりに、データと注意力を差し出している場合があります。
ここは現代の年貢です。しかも米ではなく個人情報で納める時代です。

最重要対策6：ブラウザを用途別に分ける

ブラウザは、現代の攻撃入口です。
Webサイト、広告、拡張機能、ログインCookie、ダウンロードファイルが集中しています。

一般ユーザーでも、ブラウザやプロファイルを用途別に分けるだけでリスクを下げられます。

用途 推奨運用
金融・証券 専用ブラウザまたは専用プロファイル
WordPress管理 専用プロファイル
SNS 通常プロファイル
調査・買い物 別プロファイル
怪しいリンク確認 ログインしていない環境で確認

また、ブラウザ拡張機能は必要最小限にしてください。
「すべてのサイト上のデータを読み取り、変更する」権限を持つ拡張機能は、特に慎重に扱うべきです。

最重要対策7：バックアップを攻撃後の生命線として考える

セキュリティの専門家は、完全防御を前提にしません。
重要なのは、侵害されたときに復旧できることです。

対象 バックアップ方法
写真・動画 クラウド + 外付けSSD
仕事資料 クラウド + ローカルコピー
WordPress データベース + wp-content
スマホ iCloud / Googleバックアップ
パスワード管理 緊急アクセス、復旧コード保管
2FA復旧コード 紙または暗号化保管

バックアップは、取るだけでは不十分です。
実際に復元できるかを確認して初めて、バックアップとして機能します。

生成AIサービスの利用でも情報を分ける

ChatGPT、Claude、Geminiなどの生成AIは便利ですが、入力する情報の扱いには注意が必要です。
AIに入力する情報は、外部サービスへ送信する情報であると考えるべきです。

入力を避ける情報 理由
パスワード 絶対に入力しない
APIキー 悪用されると課金や侵害につながる
秘密鍵 暗号資産やサーバー侵害につながる
本人確認書類 なりすましに悪用される可能性がある
顧客情報 情報漏えいや契約違反につながる可能性がある
社外秘資料 法務・コンプライアンス上のリスクがある
セキュリティ設定情報 攻撃者に有利な情報になり得る

日常操作のセキュリティチェックリスト

毎日意識すること

  • メール、SMS、DMのリンクを安易に開かない。
  • ログイン前にURLとドメインを確認する。
  • 身に覚えのない認証通知は拒否する。
  • 添付ファイルを開く前に送信元と内容を確認する。
  • 決済通知やカード利用通知を確認する。

毎週確認すること

  • OS、ブラウザ、スマホの更新を確認する。
  • 不要なアプリを削除する。
  • アプリ権限を見直す。
  • クレジットカード明細を確認する。

毎月確認すること

  • 重要アカウントのMFA設定を確認する。
  • パスワードの使い回しがないか確認する。
  • バックアップが取れているか確認する。
  • WordPress本体、テーマ、プラグインを更新する。
  • ルーターやNASの更新状況を確認する。

高リスクユーザーは、さらに一段上の対策を検討する

経営者、フリーランス、クリエイター、投資家、開発者、WordPress運営者は、一般ユーザーよりも狙われた場合の被害が大きくなります。

追加対策 内容
物理セキュリティキー Google、Apple、Microsoftなどの重要アカウントで利用する
専用メール 金融、管理画面、重要サービス用に分離する
専用端末 金融・業務用と普段使いを分ける
SNS管理者権限の分離 個人アカウント一本化を避ける
WordPress WAF 管理画面保護、ログイン制限、不正アクセス対策を行う
Lockdown Mode 標的型攻撃が懸念される場合に検討する

AppleはLockdown Modeについて、極めてまれで高度なサイバー攻撃から端末を保護するための任意の強力な保護機能として説明しています。
通常のユーザー全員に必要な機能ではありませんが、標的型攻撃が懸念される人には検討価値があります。

参照URL：
https://support.apple.com/en-us/105120

やってはいけない操作一覧

NG行動 理由
同じパスワードを使い回す 1件漏れると他サービスへ連鎖する
SMSリンクからログインする 偽サイトへ誘導される可能性がある
古いスマホを使い続ける セキュリティ更新が切れると危険
不明アプリに全権限を渡す 連絡先、写真、位置情報が抜かれる可能性がある
認証コードを人に教える 本物のサポート担当でも通常は不要
フリーWi-Fiで金融操作をする 偽Wi-Fiや中間者攻撃のリスクがある
復旧コードをスクリーンショット保存する 端末流出時に復旧手段まで奪われる

まとめ：AI時代の個人セキュリティは「認証・更新・分離・復旧」が柱になる

Claude Mythos Previewの登場は、単なる新しいAIモデルの話ではありません。
AIがコードを読み、脆弱性を探し、悪用可能性を検証する時代が現実味を帯びてきたということです。

その影響は、企業や政府だけでなく、一般ユーザーのPCやスマホ操作にも波及します。
特に、古い端末、未更新アプリ、使い回しパスワード、安易なSMSリンク操作は、今後さらに危険になります。

柱 やること
認証 パスキー、MFA、パスワード管理を整える
更新 OS、ブラウザ、アプリ、ルーターを最新に保つ
分離 用途別メール、ブラウザ、端末、アカウントを分ける
復旧 バックアップ、復旧コード、緊急連絡手段を準備する

最後に、一般ユーザーが最優先で取り組むべきことを並べると、次の順番になります。

  1. Google、Apple、Microsoft、メインメールにパスキーまたはMFAを設定する。
  2. OS、ブラウザ、スマホを常に最新にする。
  3. パスワードの使い回しをやめ、パスワード管理ツールを使う。
  4. 不要アプリ、不要拡張機能を削除する。
  5. 写真、動画、仕事資料、WordPressデータをバックアップする。
  6. SMS、メール、DMのリンクから直接ログインしない。
  7. 金融、SNS、ブログ管理は専用環境で扱う。

AI時代のセキュリティは、難しい専門用語を覚えることではありません。
日々の操作を少しだけ堅くすることです。

玄関に鍵をかける。
印鑑を金庫に入れる。
大事な書類は控えを取る。
昔からある当たり前の用心を、デジタル生活にも持ち込むだけです。
技術が進んでも、守りの基本は意外と古風です。
そして、その古風さがこれからのAI時代にはかなり効きます。

参照URL