AI時代エンジニアが「奪う側」に回る4つの実装。現役SaaS開発者の現場検証
「AIに自分の仕事が奪われるのではないか」という不安と、社内では生成AI推進の役割が降ってきて何から手を付ければいいのか分からない混乱。Claude Code や Cursor を日常業務で使い始めた現役エンジニアが、いま同時に抱えやすいのがこの2つです。
本記事では、奪われるのを待つのではなく、AIを武器に他部署の業務を取りに行く攻めの実装を4つ整理します。対象読者は Claude Code / Cursor を1年前後使ってきた SaaS・Web 系の現役会社員エンジニア。Anthropic 公式ドキュメントが整理し始めた Subagents・Skills・Hooks といった機能群を、組織にいる側の現場戦術に翻訳します。読み終えたあとに、社内で今日試せるアクションが3つ手元に残るところまで持っていきます。
「AIで超人化したエンジニアが非エンジニアを奪う」が現実味を帯びた1ヶ月
ここ数週間、X 上で「ゼロ人会社」「CEO 1人・社員はAIエージェント」という言葉を頻繁に見かけるようになりました。きっかけのひとつは、Anthropic が Claude Code の機能セットを Subagents・Skills・Hooks として整理し、ドキュメント化を進めたことです。
Subagents は専門役割を持つAIエージェントを並列で動かす仕組み、Skills は再利用可能な手順書を Markdown で配布する仕組み、Hooks はライフサイクルに介入してカスタム処理を差し込む仕組みです。これらを組み合わせると、ひとつの作業フロー全体を Claude Code 上に乗せ替えることが現実に近づきます。「ゼロ人会社」が極端な比喩だとしても、業務単位を AI エージェントに任せる発想自体は、もう冗談ではなくなってきました。
並行して、日本のエンジニア界隈でも「非エンジニアの仕事を AI で奪われると心配しているのは、むしろ非エンジニアの側ではないか。実態としては、AI で生産性が跳ね上がったエンジニアの方が、非エンジニアの業務領域を取りに行ける」という趣旨の議論が定期的に流れてきます。僕自身、このフレーズを目にするたびに、自分の現場感覚と一致するなと感じています。
論点の方向は揃っています。AIを使って業務を最適化したエンジニアは、自分の領域に閉じる必要がなくなった。むしろ他部署の業務を内製で引き取る方向に動ける、という話です。
現役SaaS開発者として見ている、境界線が壊れる現場
ここまでが世の中の議論の話。次に、僕自身が SaaS の開発現場で見ている景色を共有します。
僕は現役のエンジニアで、2025年あたりから AI / OCR まわりの開発を担当しています。2026年4月からは生成AIを社内にどう活用させるかを命題とした、より生成AI特化の役割になりました。日々の仕事のうち、自分でコードを書く時間はほとんど残っていません。Claude Code に「まずやらせてみたらどうだろう」と考えてから手を動かす。これが2026年に入ってからの口癖です。
最近、非エンジニア部門と一緒に仕事をする機会が増えてきました。彼らが ChatGPT や Claude でコードを出力したり、動画データから内容を評価する使い方をしているのを見て、最初は正直に怖さを感じました。境界線が壊れるとはこういうことかと。ただ、複数のツールを組み合わせて高度なワークフローを組み立てる段階にはまだなく、現時点ではエンジニアの方が一段強いという感覚はあります。とはいえ時間の問題だとも思っています。
僕自身は、その状況に対して防衛側に回るのをやめました。むしろ自分の方から、他部署の業務を奪いに行くくらいの姿勢でいます。相手は敵ではなく仲間なので、互いに侵食し合うことで会社内に健全な緊張感が生まれ、組織としての成長と、業界での立ち位置の向上につながると見ています。この前提のうえで、以降の4つの実装を整理しました。
エンジニアが「奪う側」に回る4つの実装
組織内のエンジニアが攻めに転じる実装は、ざっくり4種類に分けられます。まず俯瞰してから、それぞれを掘り下げていきます。
| 実装 | 何を奪うか | 主な相手部署 | 必要ツール | 投資コスト感 | |---|---|---|---|---| | ①ドメイン業務の自動化を引き受ける | 紙・Excel運用の処理 | 経理・営業・カスタマーサクセス | Claude Code、Anthropic API、Azure AI Document Intelligence、n8n | 月数千円〜数万円のAPI実費 | | ②社内ナレッジのRAG化と運用 | 問い合わせ対応・FAQ更新 | 情シス・人事・法務 | Claude API、pgvector、LlamaIndex | 月$50〜$300規模 | | ③Claude Code Subagents / Skillsの横展開 | ドキュメント作成・レビュー | 全部署 | Claude Code、社内Git、Notion API | Claude Code MAX 月$100〜$200 | | ④要件定義を奪う | 仕様策定・PoC企画 | 事業企画・プロダクトマネージャー | Notion、Figma、Claude Code | 既存ツール内で完結 |
順に見ていきます。
①ドメイン業務の自動化を非エンジニア部署に提案して内製する
非エンジニア部署で「Excel に手で転記している」「PDF を目視で確認している」「メールから情報を抜いて貼っている」という業務は、いまの生成AI＋OCRの組み合わせでかなり片付きます。エンジニア側から PoC を2日で出して見せると、向こうが優先順位を決め直してくれます。
僕自身、2025年3月に着手したのが請求書読み取りの精度改善でした。電気使用量や排出係数を読み取る必要があったのですが、従来のラベリング型OCRでは正解率が約1割でした。Azure の OCR でまず文字情報を取り、その結果を OpenAI の LLM で構造化解析する2段階方式に変えたところ、正解率は劇的に向上しました。これは経理・営業の業務領域にエンジニアが踏み込んだ具体例で、PoC が動き始めると要件追加の議論はエンジニア側に集まります。
実装で使えるツールはざっくり以下のとおりです。
- Anthropic Claude API — テキスト構造化に強い。Claude Sonnet 4.6 で十分
- Azure AI Document Intelligence — PDF や画像の前処理。月100ページ程度なら数十円〜数百円規模
- n8n — セルフホスト可能なワークフロー基盤。社内ネットワーク内で動かしやすい
- Claude Code — PoC コードを丸ごと書かせる
最初の一手は「対象部署の Slack を30分眺めて、繰り返し発生している転記・チェック作業を1つ拾う」です。完成品を作る必要はなく、Claude Code に2日で PoC を書かせ、向こうの担当者の前で動かして見せる。ここまでやるとプロジェクト化の話が向こうから来ます。経験上、最初の PoC は精度40〜60%程度で十分で、向こうが「あと20%上げてくれたら本番運用に乗せられる」と前のめりになった時点で要件は確定します。
②社内ナレッジのRAG化と運用までを引き受ける
問い合わせ対応・FAQ 更新・新人オンボーディングの説明など、知識の取り出しと提供を回している部署はどこの会社にも存在します。情シス・人事・法務あたりが代表的です。ここは RAG（検索拡張生成）構成がはまる領域です。
僕は2025年頃に RAG で社内チャットボットを3つ作りました。それぞれ営業向けのプロダクトFAQ、エンジニア向けの社内ライブラリ検索、人事向けの就業規則質問応答という用途別の構成です。当時の構成は、社内資料をベクトル化してデータベースに保持し、質問が来たら関連箇所を取り出して LLM に渡す、というシンプルなものです。回答精度は今となっては物足りないですが、社内では喜んでもらえて、当時の評価につながりました。
実装で詰まりやすいのはチャンク分割です。Markdown見出し単位でだけ区切ると長すぎてノイズが増え、固定文字数で機械的に切ると文脈が分断されます。500〜800文字を目安に、見出しと本文の意味的なまとまりで切るルールにしておくと、Claude にコンテキストを渡したときの精度が安定しました。評価指標は最初のうちは MRR や hit@5 を厳密に追うより、「想定質問20件を社内ヒアリングで集めて回答の正誤を人間が見る」という運用で十分機能します。
2026年現在のおすすめ構成はこのあたりです。
- ベクトルDB — PostgreSQL + pgvector が手堅い。社内DBに同居させやすく運用負荷が低い
- 検索拡張のフレームワーク — LlamaIndex または LangChain のRetrieverを薄く使う
- LLM — Claude Sonnet 4.6 ベース。日本語の長文要約と引用元提示が安定している
- UI — Slack Bolt で社内 Slack に常駐させると利用率が伸びる
注意点は、構築よりも「正解データの管理と更新運用」を引き受ける宣言までセットでやることです。RAG は投入後の鮮度維持で価値が決まります。情シス・人事側に運用を投げ返すと数ヶ月で形骸化します。エンジニア側が運用ごと巻き取ると、その業務は事実上こちらに移管されます。
③Claude Code Subagents / Skills を業務横展開のテンプレに変える
Anthropic 公式ドキュメント側で整理されてきた仕組みを、組織内応用する話です。Claude Code には Subagents と Skills という機能があります。Subagents は専門役割を持つAIエージェントを並列で動かす仕組みで、Skills は再利用可能な手順書を Markdown で配布する仕組みです。
これを社内向けに使うと、こんな展開ができます。
- 議事録の構造化Subagentを作る。会議議事録のテキストを渡すと「決定事項」「アクションアイテム」「未解決の論点」に分けて返す
- レビュー観点Skillを作る。マーケが書いたランディングページのコピーをレビューする観点（誇大表現の検出、効能と根拠の対応関係）を Markdown で配布する
- 社内Notion検索Subagentを作る。Notion API で横断検索し、関連ページの要約を返す
社内 Git に置く構成のサンプルはこんな感じです。
company-claude-pack/
├── agents/
│ ├── meeting-minutes.md # 議事録の構造化Subagent
│ ├── notion-search.md # Notion横断検索Subagent
│ └── pr-reviewer.md # 社内コードレビュー観点Subagent
├── skills/
│ ├── lp-copy-review/
│ │ └── SKILL.md # ランディングページのコピー観点
│ ├── meeting-summary/
│ │ └── SKILL.md # 議事メモから論点分離
│ └── slack-onboarding/
│ └── SKILL.md # 新人向け Slack 案内テンプレ
└── install.sh # ~/.claude 配下にシンボリックリンクを張る
ポイントは、これらを社内 Git の共有リポジトリに置き、誰でも git clone して ~/.claude/agents/ または ~/.claude/skills/ に配置すれば使えるようにすることです。中身を更新したら PR を上げて、レビューが通れば全社にロールアウトされる、という運用に乗せると、AIワークフロー自体が社内のレビュー文化に取り込まれます。「再利用可能な単位を増やすこと」が本質で、これを組織に持ち込めば1人のエンジニアが10部署分の業務テンプレを作れます。
実コストは Claude Code MAX プランで月$100〜$200程度。社内10名で共有しても、外部ベンダーに小規模ツール開発を発注するより安く済みます。
④非エンジニア部門の意思決定プロセスにエンジニアが入り、要件定義を奪う
これが一番効きます。①〜③が「実装」の話だとすると、④は「上流」の話です。
生成AI浸透担当として他部署と仕事をしていると、要件定義の場に呼ばれる回数が増えます。最初は技術的な実現可能性の質問に答える役回りですが、Claude Code でその場で叩き台の PoC を動かしてみせると、議論の主導権は自然とこちらに来ます。
具体的にやることは以下のとおりです。
- キックオフ前にSlackチャンネルを覗いておく。何が論点になっているか把握してから出席する
- 会議中に Claude Code でPoCを叩く。「いま動かしてみました」が要件議論の解像度を一段上げる
- 次の会議までに動くものを持っていく。仕様書を作るより速い
- 意思決定者と1on1を入れる。技術判断と事業判断の橋渡し役を引き受ける
ここまでやると、その部署の仕様策定と PoC 企画はあなたの仕事になります。組織図上は他部署の仕事でも、実態として要件定義を握っている人がプロジェクトの中心になります。
「奪う側」になる難しさ。組織政治と自社制約
ここまでメリット側を書いてきましたが、実装するうえで率直に難しいところもあります。3つに分けて触れておきます。
1. 「奪う」と表現すると越境・摩擦になる
社内で「あの部署の仕事を取りに行く」と言って回ると、ただの政治的な敵対行為になります。実態としてやることは奪取ですが、コミュニケーションは「一緒に解像度を上げる」「PoC を共有する」「運用を巻き取る」というスタンスを貫いた方が結果的に取れます。相手は敵ではなく仲間です。健全な緊張感は、敵対関係ではなく相互尊重の上にしか作れません。
2. コストとガバナンスは現実的な制約になる
Claude Code MAX 月$100〜$200、Anthropic API のトークン課金、社内データを LLM に渡す際のセキュリティガバナンスなど、組織内で動かすには事前合意が必要です。情報システム部・法務との合意なしに進めると、PoC が動いても本番採用が止まります。最初の1ヶ月はガバナンス整備と並走するつもりで設計してください。具体的には Anthropic の Commercial Terms を持参して、入力データの取り扱いについて法務と事前合意するところから始めるとスムーズです。
3. 全員がこの動きに乗れるわけではない
ロール・会社・時間軸の制約は人それぞれです。受託開発でクライアント業務に張り付いている、自社プロダクトの新機能開発が詰まっている、などの状況だと社内の他部署に手を伸ばす余裕は作りにくい。「奪いに行く」のは可能性の話であって、義務ではありません。自分のロールと会社の状況を見て、まずは①のドメイン業務の自動化PoCを1個出すだけでも十分前進です。
まとめ。Anthropic公式機能群を組織内エンジニアに翻訳すると
最後に要点をまとめておきます。
- 「AIに仕事を奪われる」と「AIで奪う側に回る」は同じ現象の裏表。受け身でいる限り前者になる
- 組織内エンジニアの攻めとは、ソロ独立で起業することではなく、他部署の業務を内製で取りに行くこと
- 実装は4つ。ドメイン業務の自動化／RAG運用引受／Subagents・Skillsの横展開／要件定義の奪取
- 一番効くのは④の要件定義の奪取。①〜③はそこに辿り着くための実績作り
今日から取れるアクションを3つ示して締めます。
- 自部署外のSlackを1つ覗いて、繰り返し発生している転記・確認作業を1つ拾う
- Claude Code で2日で PoC を書き、その部署の担当者の前で動かして見せる
- Anthropic 公式の Claude Code ドキュメント から Subagents / Skills のページに目を通し、社内向けに横展開できるテンプレを1つ作る
「AIで超人化したエンジニアが非エンジニアの仕事を奪う」という言い回しは挑発的ですが、組織の中では「健全な緊張感を作る側に回る」と読み替えるのが現実的です。
