【2026年版】エンジニア必見：残業を50%削減する最新生成AI“実務活用”7パターン

「ChatGPTもCopilotも一応触ったし、自分はAI遅れてないでしょ？」と思っているなら、わりと危険ゾーンかもしれません。

2026年のいま、
「たまにAIに質問する人」と「AI前提で仕事を組み立ててる人」のあいだで、冗談抜きに生産性ギャップが開き始めています。

この記事では、単なるツール紹介ではなく、「どの業務を、どうAIに任せると、どれくらい残業が減るのか」を、具体的なワークフローとプロンプト・コード例つきで解説します。

この記事を読むと、以下が分かります。

明日から試せる、エンジニア向けAI活用ワークフロー7パターン
ChatGPT / Claude / Gemini / Copilot などの使い分け指針とプロンプト例
セキュリティ・コスト・社内展開の「現実的な落としどころ」

なぜ“新世代の生成AI”を触らないとマズいのか？【3つのギャップ】
まずは現状把握：あなたの開発フロー、2026年のAI前提になってる？
1. 5分でできる生成AI活用セルフチェック【要件〜運用まで】
2. AIを挟むと“時間単価”が一気に上がる3つのポイント
実務で効いた！最新生成AIで工数を半分にした“7つのワークフロー”
じゃあ実際どう作る？シンプルな例で学ぶ“AIエージェント化”の入口
“AIを使いこなすエンジニア”だけが身につけている3つの思考パターン
よくある疑問に答えるQ&A：セキュリティ／コスト／社内展開どうする？
まとめ：まずは“1つの業務”をAIに丸ごと任せてみよう

なぜ“新世代の生成AI”を触らないとマズいのか？【3つのギャップ】

2023〜2024年あたりで「ChatGPT触ってみたし、Copilotも入れてるし、まぁ大丈夫でしょ」と思っているなら、ちょっと危ないです。

2025〜2026年の今って、
「たまにAIに質問する人」と「AI前提で仕事を組み立ててる人」のあいだに、笑えないくらいの生産性ギャップが開き始めてます。

しかも、その差を作ってるのは「才能」じゃなくて、だいたい次の3つのギャップです。

コンテキストのギャップ
ツール連携のギャップ
期待値（アウトプット基準）のギャップ

順番にいきます。

あなたの残業、実は“コンテキスト不足”が原因かもしれない

エンジニアの残業って、冷静に振り返ると「手を動かしている時間」よりも、状況を理解するまでの時間にかなり食われてませんか？

Jira / Backlog のチケット：過去コメントが長すぎて読む気がしない
Slack / Teams のスレッド：本題がどこで決まったのか分からない
仕様書：古い版と最新版が混ざってて、どれが生きてるのか謎
会議：議事録はあるけど、3回分くらい読まないと経緯が見えない

で、結果こうなるやつです。

「とりあえずこの辺り直しておきました」
「あ、それもう別の方針で決まってて…」

この「バラバラな情報を1から追う時間」が、新世代のLLMだと丸ごと飛びます。

たとえば Google DeepMind の Gemini 系最新モデル Gemini 3 Pro だと（参考：Gemini 3とは？使い方や料金プラン・できることを徹底解説！）、

入力で 最大約 1,048,576 トークン（数千ページクラス）まで一気に食わせられる
PDF、議事録テキスト、Slackログ、設計書をまとめて1プロンプトで渡せる
そのうえで「要件の決定事項」「まだグレーな点」「関係者」を構造化してくれる

具体的に何が変わるかというと：

Before
3本の議事録＋チケット＋Slack スレッドを1時間かけて読む
自分なりに「何をすべきか」をメモ化
あってるか不安なので誰かに確認（さらに時間）
After
それら全部を ZIP かコピペでモデルに投げて、プロンプト一行
- 「この機能 A について、決まっている要件・未決事項・想定ユーザー・非機能要件を箇条書きで整理して。最後に“確認した方がいい質問リスト”も出して」
出てきたサマリをざっと5分で目を通して、怪しい所だけ元データへジャンプ

この「1時間かけて解読していたコンテキストが、10分で済む」差って、
正直 Copilot のインライン補完よりインパクトでかいです。

企業はもう“AI込みのアウトプット”でエンジニアを見始めている

国内でも、だんだん空気が変わってきました。

「生成AI研修」をExcel研修と同じノリで売る企業が増えてきた
電源開発（J-POWER）のようなインフラ寄り企業ですら、
Alli LLM App MarketのオンプレAIチャットボット導入を進めて
「問い合わせを5分の1にしました」と言っていたり
Google は Gemini 3 を検索や Workspace にガッツリ統合し、
「AI前提の業務ツール」がデフォルト環境になりつつあったり

ここで地味に効いてくるのが、

「この人のアウトプットは、AIを前提にしているか？」

という新しい評価軸です。

PR の質：
テストコード・コメント・ドキュメントまでちゃんと揃っている
レガシー調査のサマリが分かりやすくまとまっている
調査力：
技術検証のメモが綺麗に構造化されている
英語記事も普通に参照してる
社内貢献：
社内向けの Q&A ボットやテンプレプロンプトを整備している

こういう部分って、一人で黙々と頑張るより、AIを味方につけた方が圧倒的に楽なんですよね。

逆にいうと、「昔ながらのやり方で一人で抱えて頑張る」スタイルは、
同じ給料でも見えないところで差がつき始めている。

採用側の視点でも、

「AI使って早くてそこそこ上手い人」
「AI使わず遅いけど昔ながらに丁寧な人」

のどちらを選ぶか？と言われると、
多くの現場は前者に寄せたい（でも安全に運用したい）というのが本音です。

モデルの“地力”が上がりすぎて、昔のイメージのままだと損する

「LLMなんて、どうせそれっぽいことを言ってるだけでしょ」

この認識、2023年で時間が止まってます。

参考までに、さっきの Gemini 3 の例をもう少しだけ。

マルチモーダル対応
テキストだけじゃなく、画像・音声・動画・PDFをネイティブに扱える
手書きメモや図入りの設計資料をそのまま投げられる
高度な推論モード（Deep Think など）
複雑な問題に対して、内部で思考ステップを増やして解くモード
科学・数学・技術系の難問ベンチマークでかなり高スコア
※現状は英語や一部リージョン限定などの制約あり
コンテキストウィンドウ
100万トークン級の長文を踏まえて考えられる
つまり「プロジェクト全体」や「社内ドキュメント山ほど」を前提に回答できる

出典：
「Gemini 3とは？使い方や料金プラン・できることを徹底解説！」（AI活用ナビ）
https://tech-camp.in/ai-navi/gemini-3/

このレベルになると、

「ファイル分割してちょっとずつ投げる」儀式がほぼ不要
会議録音をそのまま投げて、決定事項・TODO・リスクだけ抜き出すのが現実的
数万行クラスのコードベースも、「ざっくり構成」と「怪しいところ」をまとめてくれる

という、“設計・調査・レビュー”側の仕事がガッツリ変わります。

このセクションで言いたいことを一言でいうと

「チャットで質問する便利ツール」から、「業務フローに組み込む前提技術」に変わった
のに、使い方が昔のままだと、普通に不利になります。

コンテキストを丸ごと読ませて、要件整理やレガシー解析を飛ばしている人
ツール実行や社内ナレッジ検索までAIに任せている人
その前提で「アウトプットの質」と「スピード」を上げている人

この層と、たまに ChatGPT を単発で叩くだけの自分とのあいだで、
1ヶ月・3ヶ月・1年と時間が経つほど、差が積み上がっていきます。

この記事では、このギャップを埋めるために、

どのフェーズで
どのタイプのモデルを使って
どうプロンプトを書けば

明日から“残業1時間減るレベル”の効果が出るかを、
具体的なワークフローとコード断片付きで掘っていきます。

まずは現状把握：あなたの開発フロー、2026年のAI前提になってる？

いきなり「Gemini 3 すごい！」「エージェント最高！」って話をしても、
自分の開発フローにどう刺さるかイメージしづらいと思うので、
一回ここでセルフ健康診断を挟みます。

目的はシンプルで、

「自分の開発フローのどこに AI を挟めば、いちばん残業が減るか？」

をハッキリさせること。

紙でもメモアプリでもいいので、ちょっと手を動かしながら読んでみてください。

5分でできる生成AI活用セルフチェック【要件〜運用まで】

開発のライフサイクルをざっくり分けると、こんな感じですよね。

要件定義・仕様整理
設計（画面・API・DB・アーキ）
実装（コーディング）
テスト（テスト設計／テストコード）
レビュー（コード／設計レビュー）
運用・保守（障害対応・問い合わせ対応）
社内調整・ナレッジ共有（ドキュメント・社内 Q&A）

それぞれについて、今の自分を○△×の3段階でチェックしてみてください。

○：AI を“前提”に使っている（毎週使う、ワークフローに組み込んでいる）
△：たまに気が向いたら使う（単発でチャットに投げる程度）
×：ほぼ使っていない（Copilot 入ってるけど放置、など）

① 要件定義・仕様整理

Slack / Teams のスレッドや議事録を AI に渡して、
「決定事項・未決事項・TODO・リスク」を構造化させている → ○
日本語のふわっとした要求を AI に「ユーザーストーリー」や「ユースケース図」風に
まとめさせている → ○
「要件がカオスなチケットを、まず AI に要約させる」が習慣になっている → ○
たまに「要件わからん」と ChatGPT に愚痴るだけ → △
そもそも要件整理に AI を使う発想がない → ×

② 設計

画面モック・API 設計・クラス設計のドラフトを AI に書かせてから肉付けしている → ○
設計書を AI に読ませて、「懸念点」や「抜けてそうなパス」を洗い出させている → ○
「この設計どう思う？」と一応聞くけど、返ってきたものはあまり活かしてない → △
設計段階は完全に人力、AI は一切登場しない → ×

※ここは、Gemini 3 みたいな長文＋図入りの設計書を丸ごと読めるモデルを使うと一気に化けます（Gemini 3解説記事参照）。

③ 実装（コーディング）

GitHub Copilot / Cursor / Codeium などのインライン補完を常用 → ○
さらにチャット型 LLM（ChatGPT / Claude / Gemini）で
「アルゴリズム相談」「設計の意図の説明」も並行して使っている → ○
Copilot は入れているが、補完が気に入らないとオフにしがち → △
何となくコード生成を試したことはあるけど、怖くて本番では使ってない → △
エディタには AI 関連の拡張が一個も入っていない → ×

④ テスト

既存コードと仕様を LLM に読ませて、テストケース一覧＋テストコード雛形まで書かせている → ○
「pytest 用のテスト書いて」「Jest 用に変換して」みたいな指示を日常的に使っている → ○
たまにユニットテストを生成させるが、ほとんど修正が必要でイマイチ活かせてない → △
テストは全部手書き、AI は一切関与しない → ×

⑤ レビュー

PR を丸ごと LLM に渡して、「命名の一貫性」「セキュリティ／パフォーマンス懸念」などを
指摘させた上で、人間レビューに入っている → ○
レビューコメントの文面を AI に整えてもらっている（丁寧な日本語・英語に変換） → ○
ちょっとだけ「このコードの問題点ある？」と聞く程度 → △
レビューは完全に人間同士、AI は「見る専」 → ×

※ここも、Gemini 3 のような長大なコンテキストを丸ごと渡せるモデルだと、「この PR 全体の設計意図を要約して」みたいな使い方が現実的になります。

⑥ 運用・保守

障害ログやメトリクスグラフのスクショを AI に見せて、
「起きていそうな事象」「切り分け方」を提案させている → ○
障害報告メールやポストモーテムのドラフトを AI に書かせている → ○
エラー内容をそのままコピペして「なんすかこれ」と聞くくらい → △
監視・障害対応は完全に人力＋Google 検索のみ → ×

⑦ 社内調整・ナレッジ共有

社内 Wiki や Confluence の記事を AI に書かせてから、自分で修正して公開 → ○
社内専用の Q&A ボット（RAG）を検討中 or すでに運用している → ○
メール・議事録・仕様書の「いい感じの体裁」を整えるだけ AI に頼んでいる → △
ドキュメントは全部手打ち／コピペ、AI の出番はゼロ → ×

ひと通りつけてみて、○ がいくつ、△／× がどこに集中しているか眺めてみてください。

実装だけ ○ で、他は△× だと
→ 「コーディングだけ AI で、コンテキスト整理が人力地獄」パターン
要件〜設計は △× で、テスト・運用も × 多めだと
→ 「2023 年型の AI 利用で止まってる」パターン
運用・ナレッジ共有が全部 × だと
→ 「問い合わせ・調査・同じ質問が何度も飛んでくる世界」に住んでる可能性大

このあと解説する「7つのワークフロー」は、
このチェックで △ or × がついたフェーズを狙い撃ちする形になってます。

AIを挟むと“時間単価”が一気に上がる3つのポイント

自分のチェック結果を眺めながら、
ここからは「どこに AI を入れるといちばんコスパがいいか？」を絞っていきます。

2026 年時点で工数インパクトが特に大きかったトップ3はこのあたりです。

カオスな仕様・要件の整理
テストケース＆テストコード自動生成
日英ドキュメントの要約・翻訳・整形

ざっくりの時間削減イメージ付きで。

① カオスな仕様・要件の整理（−60〜90分／週くらい）

典型パターン：

Slack スレッドが 300 メッセージ
会議が 2 回分
チケットコメントが 20 個
仕様書が 30 ページ

「新機能 B の要件を把握するだけ」で2〜3 時間飛ぶやつです。

ここに、Gemini 3 みたいな長文＋マルチモーダル OK なモデルを投げると：

PDF／議事録テキスト／チャットログを全部まとめて食わせる
プロンプト例：

「この機能 B に関する資料をすべて読んで、
1. 目的
2. 想定ユーザー
3. 機能要件
4. 非機能要件（パフォーマンス・セキュリティなど）
5. 未確定事項と、誰に聞くべきか
を日本語で箇条書きにしてください。」

10〜15 分あれば、人間が1時間かけてやる要件整理の“叩き台”が出てくる

② テストケース＆テストコード自動生成（−2〜4時間／週くらい）

仕様はある
コードもある
でもテストが薄い（or ない）

というプロジェクト、まだまだ多いと思います。

ここで ChatGPT / Claude / Gemini 3 クラスのモデルに、

対象クラスや関数のコード
関連する仕様書 or チケット
既存のテスト（あれば）

を渡して、

「Jest 用に、重要なパスと境界値・例外系をカバーするテストケース一覧を挙げて。
そのうえで、テストコードのドラフトを書いて。」

と指示すると、

テストケースの列挙
それをもとにしたテストコードの雛形

まで一気に出せます。

完全自動は危険ですが、体感としては、

Before：テスト設計＋実装で 1 日仕事
After：AI のドラフトを修正していく形で、半日〜数時間

くらいまで短縮できます。

③ 日英ドキュメントの要約・翻訳・整形（−1〜3時間／週くらい）

英語の OSS ドキュメント
海外製ミドルウェアのマニュアル
社内の長文仕様書や議事録

を読む／書くのに、地味に時間持っていかれてませんか。

新世代の LLM（とくに Gemini 系はマルチモーダル＋翻訳が強い印象）を使うと、

長文ドキュメントを要点 5〜10 個の箇条書きに要約
英語 → 日本語、日本語 → 英語の意訳ベースの変換
README / ADR / 議事録のフォーマット整形

がかなり精度高くこなせます。

セルフチェックで △／× が多かったフェーズと、
この「インパクト大の3ポイント」が重なっているところが、

あなたの開発フローにおける「AI 最優先観光スポット」

です。

このあと紹介する「7つのワークフロー」は、
まさにそこを狙い撃ちにした内容です。

実務で効いた！最新生成AIで工数を半分にした“7つのワークフロー”

ここからが今日のメインディッシュです。

「AIすごい」は一旦忘れて、
「どの作業を、どうAIに投げたら、どれくらい楽になるか」だけに絞っていきます。

それぞれ、

Before：AIなしでやってた頃
After：AIを組み込んだフロー
使うモデル／ツール
プロンプト例
注意点

の形でサクッとまとめます。

① 要件と仕様整理：Slackカオス会話→“要件定義書ドラフト”を自動生成

Before：会話ログを読むだけで1〜2時間溶ける

Slack のスレッド 300 メッセージ
会議が 2 回分（議事録はあるけど長い）
Jira チケットのコメント 30 個

これを読んで「で、結局何作るの？」を整理するだけで、
平気で半日消えるやつです。

After：全部まとめて突っ込んで「要件ドキュメントの叩き台」を吐かせる

Gemini 3 Pro などの長文モデルなら、これを1回のプロンプトに全部載せられます（Gemini 3解説）。

やること：

Slack スレッドをテキスト化（エクスポート or コピペ）
議事録とチケットを PDF / テキストで用意
まとめてモデルにアップロード
以下のようなプロンプトを投げる

あなたはWebサービス開発チームのプロダクトマネージャーです。

添付した資料（Slackログ、会議議事録、チケットコメント）をすべて読み、
新機能「プロジェクト共有リンク機能」について、以下の項目を日本語で整理してください。

1. 背景・目的
2. 対象ユーザーと利用シナリオ
3. 機能要件（ユーザーストーリー形式で3〜7個）
4. 非機能要件（性能・セキュリティ・運用）
5. まだ決まっていない論点と、誰に聞くべきか
6. 想定されるリスクと簡単な対策案

出力形式は、Markdownの見出し付き仕様書のドラフトにしてください。

モデル候補

Gemini 3 Pro / 3.1 Pro（長文＋PDF＋マルチモーダル）
Claude 4.x
GPT-4.1 / GPT-4.5 Turbo

注意点

古い議事録が混ざるなら「最新の日付の決定を優先」と明示
機密が心配なら、まずはダミーログでワークフロー検証から

② 設計レビュー：AIに“うるさいシニアエンジニア役”をやらせる

Before：設計レビューの時間が足りない／観点が偏る

設計が PR レビューのついで扱い
人によって見るところがバラバラ（命名警察だけ発動しがち）

After：AIに観点リストを総当たりさせて“指摘のたたき台”を作る

仕様書 or 設計ドキュメント（Markdown / Confluence / 図のスクショ）を丸ごと投げて：

あなたはバックエンドのシニアエンジニアです。
以下のAPI設計書について、設計レビューを行ってください。

レビュー観点は以下とします。

- 想定される障害パターン（タイムアウト、リトライ、冪等性など）
- スケーラビリティ（将来的な負荷増大に耐えられるか）
- セキュリティ（認証・認可・入力検証などの抜け漏れ）
- ドメインモデルとエンティティの責務の分離
- 命名の一貫性と可読性

各観点について、
1. 問題がありそうな点
2. なぜ問題になりうるか（理由）
3. 改善案の例

を箇条書きで出してください。
最後に、「特に優先して直した方がよい点」を3つだけ挙げてください。

図入りの設計（シーケンス図のPNGとか）も、Gemini 3 のマルチモーダルなら一緒に読めます。

注意点

「優先度を付けて」と必ず指示
指摘を全部真に受けず、「うちのコンテキスト的に要る／いらない」は人間が判断

③ 実装スピード3倍：Copilot×チャット型AI×長文モデルの“3刀流”コーディング術

Before：Copilotだけ or チャットだけで中途半端

Copilot の提案が気に入らずオフにしがち
別タブの ChatGPT を開くのが面倒で使わなくなる

After：“手を動かすAI”と“考えるAI”を役割分担

インライン補完（手の動き担当）
Copilot / Cursor / Codeium
ループやDTO、APIクライアントなど定型処理を任せる
チャット型 LLM（設計・アルゴリズム相談担当）
VS Code 拡張の Copilot Chat / Claude / Gemini
選択コードを「日本語で説明して」「エッジケース3つ出して」と聞く
長文モデル（プロジェクト全体担当）
Gemini 3 Pro / Claude 4.x
PR 一式＋設計書を読ませて「影響範囲」や「設計意図の要約」を出させる

小ワザ

コメントで意図だけ書いてから Copilot にコードを書かせる
チャット側には「このプロジェクトの目的／品質基準」をテンプレで毎回添える

④ テストコード自動生成：カバレッジ30％→80％まで持っていく現実解

Before：テスト設計に時間がかかりすぎて後回し

ハッピーパス中心、境界値・例外は薄め
結局「テスト書く時間がない」パターン

After：“テストケース列挙＋コード雛形”をAIに丸投げ

Python×pytest の例：

対象コード＋関連仕様を貼る
まずは「テストケース一覧」だけを生成させる

以下のPythonコードと仕様を読んでください。
この関数について、pytest形式でテストすべきケースを列挙してください。

- 正常系（代表的なパターンを3〜5個）
- 境界値（0、最大値、Noneなど）
- 例外系（例外を投げるべき入力）

各テストケースについて、
1. 入力値
2. 期待される出力または例外
3. そのケースが必要な理由

を表形式で出してください。

表を人間が編集
最後に「この表をもとにpytestのテストコードを書いて」と依頼

モデル候補

GPT-4.1 / GPT-4.5 / GPT-o3 系
Gemini 3 Pro（Google曰く「世界最高峰のコーディング性能」クラス。出典：Gemini 3解説）
Claude 4.1 Sonnet / Opus

注意点

境界値・例外系だけは必ず自分で目視チェック
既存テストとの重複や命名衝突に注意

⑤ レガシーコード解析：2万行の沼を“30分で鳥瞰図”にする読み解き術

Before：レガシーに着任した瞬間に心が折れる

コメントゼロ
SomethingManager と SomethingService だらけ
2万行ファイルが鎮座

After：AIに「構成図」と「怪しいところリスト」を描かせる

サブディレクトリ単位でコードを固める
長文モデルに投げて、以下を出させる：

あなたはレガシーシステムの解析を行うシニアエンジニアです。
添付したコード一式について、以下を出力してください。

1. パッケージ・ディレクトリ構成の概要（役割と依存関係）
2. 主要なクラス／関数と、その責務の一覧
3. グローバル変数／シングルトン／静的メソッドなど、保守性を下げている要素
4. バグが発生しやすそうな箇所（条件分岐が複雑なところ、状態管理が分散しているところ 等）

最後に、「最初に読むべきファイル3つ」と「触るときに特に注意が必要なファイル3つ」を挙げてください。

さらに「この3ファイルの関係をシーケンス図風に説明して」と追い打ち

効果

「どこから読むか分からない」状態から脱出
最初の30分で、全体像と地雷ポイントが把握できる

⑥ ドキュメント＆コメント生成：日英ドキュメントを“AI管理”に任せる

Before：コメント・README・仕様書がいつも後回し

実装優先でドキュメントが腐る
英語ドキュメントがしんどくて海外メンバーとギャップ

After：“コード→コメント・ドキュメント”を半自動生成

例：TypeScript から JSDoc 自動付与

以下のTypeScriptコードに対して、JSDocコメントを追加してください。

要件：
- 各関数の直前に、日本語の説明付きJSDocを付ける
- パラメータ、戻り値の型と説明を記載する
- 非同期関数には、エラーになりうる条件を @throws で記述する

出力はコード全体をJSDoc付きで返してください。

README や API ドキュメントも同様に、
「含めたい項目」を箇条書きして渡すと一気にドラフトを作ってくれます。

モデル候補

Gemini 3 Pro（マルチモーダル＋翻訳が強い。出典：Gemini 3解説）
Claude 4.1（長文・日本語がかなり自然）
GPT-4.1 / 4.5

注意点

プロジェクト固有用語は「用語集」を一緒に渡すと訳ブレが減る
英語版はチーム方針に応じてネイティブチェックするか決める

⑦ 問い合わせ対応＆運用：RAG＋社内ナレッジで“なんでも屋ボット”を作る

Before：同じ質問がSlackに何度も流れてくる地獄

「VPN どこから繋ぐんでしたっけ？」
「経費精算の締めいつでしたっけ？」
「このジョブ落ちてるけど、どこ見ればいいですか？」

J-POWER の事例でも、年末調整や館内ルールの問い合わせが多すぎて、
オンプレのAIチャットボット「Alli」で問い合わせを約1/5に削減したという話があります（出典：導入事例【電源開発（J-POWER）様】）。

After：社内ナレッジ＋RAGで“聞けばだいたい答えてくれるボット”

ミニマム構成：

社内Wiki／運用手順書／FAQ を PDF / Markdown で集める
ベクターストアに投入（RAG 用）
フロントは Slack Bot やシンプルなWeb UI
LLM に「社内文書を優先して回答する」ルールを埋め込む

コアプロンプト例：

あなたは社内ヘルプデスクボットです。
ユーザーからの質問に対して、まず関連しそうな社内ドキュメントを検索し、
その内容をもとに回答してください。

ルール：
- 回答の根拠となるドキュメント名とセクションを必ず併記する
- ドキュメントに情報がない場合は、「わからない」と答え、問い合わせ先を提案する
- 機密情報（個人情報・パスワードなど）は絶対に出力しない

回答は日本語で、箇条書きを中心に簡潔に書いてください。

注意点

機密情報が絡むならオンプレ／専用環境が前提
いきなり全社対応にせず、「よくある質問10〜20個」から始めて育てる

ここまでが「残業を半分にする7つのワークフロー」です。
どれか1つでもハマると、普通に毎週1〜2時間は戻ってきます。

次は、「じゃあそれ実際どう作るの？」という話を、
Python×LLM APIのミニエージェント作成例で見ていきます。

じゃあ実際どう作る？シンプルな例で学ぶ“AIエージェント化”の入口

ここまで読んで、

「ワークフローでAIを挟むイメージはわかった」
「でも、自分で“ちょっとしたエージェント”を作るって何からやれば？」

となってる人、多いと思います。

なのでこのパートでは、

1つの仕事を、継続的に任せられる小さなAIエージェント

を、ローカル環境＋LLM API＋Pythonだけで作るところまでをイメージしてもらいます。

テーマはシンプルに：

GitHub Issues や Jira チケットを読んで
要約＋優先度ラベルを付けて
Slack に投げる

という「チケット要約ボット」です。

Python×LLM APIで作る「チケット要約ボット」【最小構成のコード例付き】

全体像：やることは4ステップ

チケット情報を取ってくる（GitHub / Jira API）
1件ごとに LLM に投げて、「要約＋優先度」を返してもらう
結果を整形して Slack に投げる
「どこまで自動でやるか」を設定で制御する

構成イメージ：

GitHub / Jira -> Pythonスクリプト -> LLM API -> Python -> Slack

※コードは雰囲気重視のサンプルなので、本番なら例外処理など足してください。

依存ライブラリと環境変数

pip install requests python-dotenv

.env：

GITHUB_TOKEN=ghp_xxxxx
GITHUB_OWNER=your-org
GITHUB_REPO=your-repo

LLM_API_KEY=sk-xxxxx
LLM_API_BASE=https://api.openai.com/v1 # or Gemini/Claude等のエンドポイント

SLACK_WEBHOOK_URL=https://hooks.slack.com/services/xxx/yyy/zzz

Python 側：

from dotenv import load_dotenv
import os

load_dotenv()

GITHUB_TOKEN = os.environ["GITHUB_TOKEN"]
GITHUB_OWNER = os.environ["GITHUB_OWNER"]
GITHUB_REPO = os.environ["GITHUB_REPO"]

LLM_API_KEY = os.environ["LLM_API_KEY"]
LLM_API_BASE = os.environ.get("LLM_API_BASE", "https://api.openai.com/v1")

SLACK_WEBHOOK_URL = os.environ["SLACK_WEBHOOK_URL"]

Step1：Issue を拾ってくる

import requests
from typing import List, Dict

def fetch_issues_to_triage(limit: int = 10) -> List[Dict]:
    url = f"https://api.github.com/repos/{GITHUB_OWNER}/{GITHUB_REPO}/issues"
    headers = {"Authorization": f"token {GITHUB_TOKEN}"}
    params = {
        "state": "open",
        "labels": "triage",
        "per_page": limit,
    }
    resp = requests.get(url, headers=headers, params=params)
    resp.raise_for_status()
    issues = resp.json()

    # PR を除外
    issues = [i for i in issues if "pull_request" not in i]
    return issues

Step2：LLMで「要約＋優先度ラベル」を付ける

import json

def classify_issue_with_llm(issue: Dict) -> Dict:
    title = issue["title"]
    body = issue.get("body") or ""

    system_prompt = """
あなたはソフトウェア開発チームのテックリードとして、Issueの一次トリアージを行います。

以下のGitHub Issueについて、
1. 日本語で200文字以内の要約
2. 優先度（HIGH / MEDIUM / LOW のいずれか）
3. 主なカテゴリ（バグ / 機能追加 / 仕様確認 / 質問 のいずれか）
4. チームに共有すべき補足があれば1〜2文

をJSONで出力してください。

出力例:
{
  "summary_ja": "...",
  "priority": "HIGH",
  "category": "バグ",
  "note": "..."
}
    """.strip()

    user_content = f"# Title\n{title}\n\n# Body\n{body}"

    payload = {
        "model": "gpt-4.1-mini",  # 任意のモデルIDに変更可
        "messages": [
            {"role": "system", "content": system_prompt},
            {"role": "user", "content": user_content},
        ],
        "temperature": 0.2,
    }

    headers = {
        "Authorization": f"Bearer {LLM_API_KEY}",
        "Content-Type": "application/json",
    }

    resp = requests.post(f"{LLM_API_BASE}/chat/completions",
                         headers=headers,
                         data=json.dumps(payload))
    resp.raise_for_status()
    data = resp.json()

    content = data["choices"][0]["message"]["content"]
    try:
        result = json.loads(content)
    except json.JSONDecodeError:
        result = {
            "summary_ja": content[:200],
            "priority": "MEDIUM",
            "category": "不明",
            "note": "",
        }

    return result

ポイントは、

役職・出力形式をガチガチに指定していること
temperature を低めにして毎回ブレさせないこと

Gemini 3 を使う場合は、エンドポイントとペイロード形式を Gemini API に合わせればOKです（料金は 1M トークン単位など。出典：Gemini 3解説）。

Step3：Slackに投げる

def post_to_slack(issue: Dict, triage: Dict):
    url = SLACK_WEBHOOK_URL

    issue_url = issue["html_url"]
    title = issue["title"]

    summary = triage["summary_ja"]
    priority = triage["priority"]
    category = triage["category"]
    note = triage.get("note", "")

    text = f"""
*新規Issueの自動トリアージ結果です*

*[{title}]({issue_url})*

• 優先度: `{priority}`
• カテゴリ: `{category}`

*要約*
> {summary}

*補足*
> {note or '（なし）'}
""".strip()

    payload = {"text": text}
    resp = requests.post(url, data=json.dumps(payload))
    resp.raise_for_status()

Step4：全部つなげる

def main():
    issues = fetch_issues_to_triage(limit=5)
    if not issues:
        print("triage 対象のIssueはありませんでした")
        return

    for issue in issues:
        triage = classify_issue_with_llm(issue)

        # HIGH/MEDIUM だけSlackに通知
        if triage["priority"] in ("HIGH", "MEDIUM"):
            post_to_slack(issue, triage)
        else:
            print(f"LOW優先度としてスキップ: #{issue['number']} {issue['title']}")

if __name__ == "__main__":
    main()

これを cron で回す or GitHub Actions から叩けば、

「新しいIssueが立つたびに、誰かが一生懸命読んで“とりあえず”ラベルを付けていた」

みたいな仕事を、“AIテックリード”に丸っと任せられるようになります。

プロンプト設計のツボ：エージェントには“役職・権限・KPI”を与えろ

さっきの system_prompt には、エージェント設計のエッセンスが入ってます。

「あなたはソフトウェア開発チームのテックリードとして、Issueの一次トリアージを行います。」

この一文で、

役職（テックリード）
仕事（一次トリアージ）

が決まり、AI の振る舞いがかなり安定します。

雑プロンプトとの比較

NG版

以下のIssueを日本語で要約して、優先度も教えてください。

改善版

あなたはWebプロダクト開発チームのテックリードです。
目的は、チームの開発リソースを効率的に使うために、Issueの一次トリアージを行うことです。

以下のIssueについて、
- 200文字以内の日本語要約
- 優先度（HIGH / MEDIUM / LOW）。HIGHは「今週中に誰かが見るべき」レベルにだけ付ける
- カテゴリ（バグ / 機能追加 / 仕様確認 / 質問）
- 担当者が最初に確認すべきポイントを1〜2文

をJSON形式で出力してください。

優先度は、ユーザー影響範囲と緊急度のバランスで判断してください。

後者の方が、

優先度のブレが減る
要約の粒度が揃う
コメントが具体的になる

という“使える叩き台”になります。

エージェント用プロンプトの汎用テンプレ

あなたは【役職・ロール】です。
目的は【KPIやゴール（できれば数値）】を達成することです。

これから【対象データ】が与えられます。
あなたの権限は【どこまで自動で判断してよいか】です。

あなたのタスクは以下の通りです：

1. 【ステップ1：例）要約・分類】
2. 【ステップ2：例）優先度判定】
3. 【ステップ3：例）次に取るべきアクションの提案】

出力は、必ず【形式（JSON / Markdown表 / 箇条書きなど）】で出してください。

判断ルール：
- 【ルール1：例）HIGHは◯◯のときだけ】
- 【ルール2】
- 【ルール3】

それでは始めてください。

この「仕事の設計書を、プロンプトの中に一緒に書く」感覚を掴むと、
単発チャットから“AIエージェント化”に一気に踏み出せます。

どこまで任せて、どこを人が握るか

エージェントを作るときの現実的な設計は、以下の三層に分けることです。

入力を整える：人間 or 既存システム
たたき台を作る：AIエージェント
最終決定と例外処理：人間

今回のチケット要約ボットだと、

入力：GitHub Issues
たたき台：要約＋優先度＋カテゴリ（AI）
最終決定：Slack を見た人がラベルを本採用 or 修正

このサイズ感でも、
毎日 5〜10 件の Issue を人力でトリアージしていたチームなら、
週あたり1〜2時間は普通に戻ってきます。

“AIを使いこなすエンジニア”だけが身につけている3つの思考パターン

同じ Gemini / ChatGPT / Claude を触っているのに、

「なんか微妙だな」で終わる人
「気づいたら毎日使ってて、残業減ってる人」

に分かれるのは、だいたい次の3つの思考パターンの差です。

思考法1：いきなり丸投げせず、“分解してから頼む”

「仕様書書いて」
「テストコード全部書いて」
「このレガシーいい感じにリファクタして」

これはエンジニアに対してもダメ上司ムーブですが、AI相手でも同じです。

使いこなす人がやっているのは：

まずタスクを要素分解してから、1ステップずつ任せる

例：「仕様書を書いてほしい」場合

NG：

  この新機能の仕様書を書いてください。

OK：

  これから新機能の仕様をまとめたいです。

  まずは「前提条件」と「対象ユーザー」だけ洗い出してください。
  そのあとで「機能要件」「非機能要件」「代表的なユースケース」と
  順番に一緒に整理していきたいです。

  ステップ1として、以下の情報を元に、
  - 前提条件
  - 対象ユーザー
  だけを日本語で箇条書きしてください。

長文コンテキスト対応モデルでも、「分解して頼む」癖をつけた方が、

無駄にデータを投げない
どこで間違ったか追いやすい

ので、精度も再現性も上がります。

思考法2：AIのアウトプットは“出来のいい叩き台”と割り切る

AIの出力を「正解」だと思うと、ほぼ確実に事故ります。

「お、いい感じのリファクタ案出してきたじゃん」
→ そのまま採用
→ 本番で微妙なバグ
→ デバッグしたらロジックが根本からズレてた

…という黒歴史を一度は踏む。

そこでスタンスを変えます。

AIは“優秀な新人 or 後輩”
出してくるのは“そこそこ出来のいい叩き台”

という前提で、

目的を明確にしてドラフトを書かせる
自分で読みながら「合ってる／怪しい」をマーク
怪しいところは仕様 or ソースを見て裏を取る
最後に「自分の名前で出しても恥ずかしくないか」で調整

までやると、

「AIを使うと品質が落ちる」 → 「AIを使うと品質も上がる」

側に行けます。

思考法3：“自分の得意分野×AI”でレバレッジをかける

AI界隈を追ってると、

「RAGもエージェントもフロントもMLOpsも全部知らなきゃ…」

みたいな謎の焦りが生まれがちですが、
現実的には自分の得意領域×AIの掛け算を決め打ちした方がコスパ良いです。

例：

フロント × 生成AI
デザインモック→UIコードの自動生成フロー
画像生成＋Generative UI（Gemini 3のDynamic View的なやつ）で管理画面半自動生成
SRE / インフラ × 生成AI
ログ＋メトリクススクショからインシデント一次原因候補出し
Playbook（運用手順書）RAG化で、障害時の「まず見る場所」を教えてくれるボット
業務システム / 情シス × 生成AI
社内FAQ・規程・マニュアルで、J-POWERの Alli 風ヘルプデスクボット
議事録＋チケット＋メールをまとめた「今週の開発トピックまとめ」自動生成
データ分析 / ML × 生成AI
SQL / pandas / dbt の定型処理をAIに書かせて、自分は仮説検証に集中
分析レポートの自然言語サマリを自動生成

「自分の得意分野＋1ツール or 1モデル」くらいからで十分です。

3つの思考パターンのまとめ

丸投げせず、タスクを分解してから頼む
AIのアウトプットは「優秀な後輩のドラフト」としてレビューする
「自分の得意分野 × AI」でレバレッジポイントを決め打ちする

モデル名・バージョンは1年でコロコロ変わりますが、
この3つの思考パターンは、Gemini 3だろうがGPT-5だろうが一生使い回せるスキルです。

よくある疑問に答えるQ&A：セキュリティ／コスト／社内展開どうする？

ここまで読んで、

「やってみたい気持ちはある」
「でもウチの会社、情報セキュリティ部門が鬼なんだよな…」
「有料プランって、ほんとに元取れるんですか？」

みたいな“現実の壁”も見えてきたと思います。

日本の現場でほぼ必ず出る3つの質問に、数字と現実ライン込みで答えます。

Q1：機密情報をAIに投げても大丈夫？

結論：

ガチ機密は“そのまま”投げない
ただし工夫すればかなりの範囲は安全に活用できる

パターンA：まずは“疑似データ”でワークフローを作る

顧客名→CUSTOMER_001
住所→TOKYO_XXX
金額→スケールだけ合う適当な数値

みたいなダミー資料で、

要件整理フロー
テスト自動生成フロー
議事録→仕様化フロー

をまず作ってしまう。その後クローズド環境に移植する、というやり方です。

パターンB：パブリックLLMを使うけど情報を“弱めて”投げる

顧客名・社名・メールアドレスをマスキングしてから投入
IDや生データ部分も置換
「この資料は架空で個人情報を含まない」と明記

Gemini 3 / ChatGPT / Claude の商用プランは、
「学習に使わない設定」や暗号化などが前提ですが（詳細は各社ポリシー参照）、
それでもマスキングはやっておく方が無難です。

パターンC：ガチ社外秘はオンプレ／専用環境

顧客の個人情報
未発表サービスの詳細仕様
詳細なインフラ構成

この辺はオンプレ or VPC内のLLM、もしくは専用契約一択です。

J-POWER はまさにこのパターンで、
オンプレ版のAlliチャットボット導入で、年末調整などの問い合わせを1/5に削減しました（導入事例）。

Q2：有料プランにお金をかける価値って、どこで元が取れるの？

月 2,000〜3,000円の AI サブスク（ChatGPT Plus / Gemini AI Pro / Claude Pro など）は、
「週1〜2時間の工数削減」で余裕でペイするレベルです。

ざっくり試算：

あなたの社内時給：3,000〜5,000円（年収600〜900万クラス）
月3,000円のサブスク ≒ あなたの1時間未満の人件費

削減イメージ：

要件整理：週1時間削減
テスト生成：週1時間削減
ドキュメント要約・翻訳：週30分削減

→ 週2.5時間 × 3,000円 = 月7,500円相当
→ サブスク3,000円は余裕で回収できます。

上司を説得するテンプレ

数字を添えてこんな感じでSlackすると通りやすいです。

Gemini 3 / ChatGPT の有料プランを試したいと考えています。

・月額：2,900円
・使いみち：
  - 要件整理（Slackログ＋議事録の要約）
  - テストコードのドラフト生成
  - 英語ドキュメントの要約／翻訳

ざっくり試算ですが、
- 要件整理で週1時間、
- テストコードで週1時間、
- ドキュメントで週30分、
合計で週2.5時間程度の削減が見込めます。

自分の人件費を時給3,000円と仮定すると、
月におよそ30,000円分の工数削減に相当し、
月額2,900円の投資は十分ペイすると考えています。

まずは3ヶ月だけ試してみて、
・どれくらいの時間削減になったか
・他のメンバーにも展開できそうか
をレポートする形でもよいでしょうか？

Q3：チーム全体にAI活用を広げるには？【日本の開発組織向け】

一人だけAIを使いこなしていても限界があります。
とはいえ、いきなり「明日から全員AI使え」は無謀です。

おすすめは4ステップ：

小さい成功例を自分 or 小チームで作る
5分LTで共有（スクショ＋Before/After）
プロンプトテンプレと手順を Notion / Confluence に置く
最低限のルールとガイドラインを整備

特に効果があるのが「テンプレの共有」です。

テストコード生成用プロンプト
要件整理プロンプト
設計レビュー用プロンプト

をコピペ可能な形で置いておくだけで、
AI苦手層の参入ハードルが一気に下がります。

最後に、「入力していい情報・ダメな情報」の線引きだけは、
情報システム部門＆法務と一緒に決めておきましょう。

まとめ：まずは“1つの業務”をAIに丸ごと任せてみよう

ここまでかなり盛りだくさんだったので、最後に要点だけ締めます。

今日のポイント3行まとめ

生成AIを「なんとなくチャットする相手」として使っているだけだと、効果はほぼ出ない。
要件整理・テスト生成・レガシー解析・社内QAボットなど、業務フロー単位で組み込むと、残業がガッツリ減る。
新世代モデル（Gemini 3 のような長文＋マルチモーダル対応）の強みは「コンテキストを丸ごと扱えること」。
Slackログ・議事録・仕様書・コード・PDFを一気に読ませて、要約・構造化・たたき台作成を任せるのが、いま一番コスパのいい使い方。
“AIをうまく使えるエンジニア”は、ツール知識より思考パターンで差がつく。
「分解してから頼む」「叩き台としてレビューする」「自分の得意分野×AIに絞る」この3つだけでも、アウトプットの質とスピードはかなり変わる。

明日からできる“最初の一歩”チェックリスト

✅ ステップ1：一番しんどい作業を1つだけ書き出す

正直これが一番だるい…という作業を1つだけメモ
週次会議ログの要点まとめ
テストケース洗い出し
レガシーコード着任時のキャッチアップ
社内からの同じ質問への回答など

✅ ステップ2：この記事の“7パターン”のどれに近いか当てはめる

要件・仕様整理
設計レビュー
実装3刀流
テストコード自動生成
レガシーコード解析
ドキュメント＆コメント生成
問い合わせ対応＆運用ボット

✅ ステップ3：近いパターンの“プロンプト1個だけ”を真似してみる

対応するセクションに戻って、プロンプトをそのままコピペ
うまくいったらスクショ or 手順を軽くまとめて、
チームSlackに「これで○○が30分短縮できました」と投げてみる

この「小さい成功体験」を一回でもやると、
「AI使うのめんどい」→「ここはAIに投げたほうが早い」に感覚が切り替わります。

もっと踏み込みたい人向け：次に追いかけると捗るテーマ

プロンプト設計の基礎＋新世代モデル向けの書き方
タスク分解、JSON出力、役職・KPI設計のコツ
RAG×社内ドキュメントで“自社専用チャットボット”を作る話
オンプレ前提構成（J-POWER事例のようなケース）
ベクターストア選定・文書分割の実装テクニック
日本企業での生成AI・AIエージェント導入事例とスタックまとめ
どの会社がどのモデル／サービスをどう組み合わせているか
情シス／セキュリティとの“社内政治”をどう乗り切ったか

最後にもう一度。

“1つの業務”を丸ごとAIに任せるところから始める。

ここさえ踏み出せれば、
Gemini 3 だろうが GPT だろうが Claude だろうが、
あとは道具を差し替えながらアップデートしていくだけです。

明日のタスクの中から「一番めんどくさいやつ」を1つピックアップして、
この記事のどれかのプロンプトを雑にコピペしてみてください。

そこから先は、けっこう楽しくなります。

参考記事: DeepMind - Gemini 3.1 Pro: A smarter model for your most complex tasks