0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

【SE必見】マイGPTは“プロンプト集”ではない。あなたの開発現場を変える「業務特化AIエージェント」だ

0
Posted at

MYGPT.png

はじめに

エスプリフォートでは、ITの力でお客様のビジネスを支え、笑顔と価値を創造することを大切にしています。
私たちが求めているのは、単にコードを書く人ではありません。

お客様の困りごとを見つけ、
仲間と協力し、
技術を使って価値に変え、
「あなたがいてくれて助かった」と言われるエンジニアです。

エスプリフォートのクレドには、社員一人ひとりの幸せ、仲間への尊重、顧客価値の創造、チャレンジ精神、本質を見つめる姿勢が込められています。
そして、エスプリフォートは品質・ビジネス視点・人財を柱に、顧客価値を生むソフトウェア開発を大切にしています。

だからこそ、今のAI時代において私たちはこう考えています。

AIを使えるだけのエンジニアでは足りない。
AIを業務に組み込み、チームとお客様の成果を変えられるエンジニアこそ、これから本当に強い。

その第一歩として、今回紹介するのが マイGPT です。

マイGPTとは何か?

マイGPTとは、ざっくり言えば、

自分専用・チーム専用・業務専用に育てられるChatGPT

です。

通常のChatGPTは、毎回こちらが前提やルールを説明する必要があります。

たとえば、

「この会社の文体はこう」
「この設計書のフォーマットに合わせて」
「コードレビューではこの観点を見て」
「障害報告はこの粒度でまとめて」
「お客様向けなので専門用語を減らして」

こういった指示を毎回書くのは面倒です。

しかしマイGPTを作れば、最初からそのルールを持った状態で動かせます。

OpenAI公式でも、GPTsは「instructions」「knowledge」「capabilities」「apps」「actions」などを組み合わせ、特定目的に合わせた体験を作れるものと説明されています。(OpenAI Help Center)

つまり、マイGPTは単なるチャットではありません。

あなたの仕事の型を覚えた、業務特化のAIアシスタントです。

SEにとって、マイGPTが強烈に役立つ理由

エンジニアの仕事は、コードを書くことだけではありません。

むしろ実務では、次のような作業にかなり時間を使います。

  • 仕様の整理
  • 設計書の作成
  • コードレビュー
  • テスト観点の洗い出し
  • 障害調査メモの整理
  • お客様向け説明文の作成
  • 議事録作成
  • 課題管理
  • 若手への説明
  • 既存ソースの理解
  • 手順書作成
  • ナレッジ共有

これらはすべて、マイGPT化できます。

しかも重要なのは、
単に作業を早くするだけではない
という点です。

マイGPTをうまく作れば、チーム内の属人化を減らせます。

「あの人しかレビュー観点を持っていない」
「あの人しか設計書の書き方を知らない」
「あの人しかお客様向けの説明文を作れない」
「あの人しか障害報告をまとめられない」

こういう状態を減らせるのです。

これはSEにとってかなり大きいです。

なぜなら、開発現場で本当に価値があるのは、
自分だけができる状態を作ることではなく、チーム全体で成果を再現できる状態を作ること
だからです。

まず作るべきマイGPT 7選

1. 設計書レビューGPT

設計書を貼り付けると、以下の観点でレビューしてくれるGPTです。

  • 要件とのズレ
  • 曖昧な表現
  • 入力チェック漏れ
  • 例外処理漏れ
  • 権限考慮漏れ
  • データ整合性
  • 画面遷移の不自然さ
  • 運用時に困りそうな点
  • テストしにくい仕様

これはかなり実務で使えます。

特に若手SEが作成した設計書に対して、先輩が毎回ゼロから見るのではなく、まずマイGPTで一次レビューする。
そのうえで人間が最終確認する。

これだけでレビュー品質も速度も上がります。

設定例

あなたは業務システム開発に強いシニアSEです。
入力された設計書を、以下の観点でレビューしてください。

1. 要件との整合性
2. 曖昧な表現
3. 入力チェック
4. 例外処理
5. 権限
6. データ更新・整合性
7. 運用影響
8. テスト観点

出力は以下の形式にしてください。

- 指摘箇所
- 問題点
- 想定されるリスク
- 修正案
- 優先度(高・中・低)

2. ソース解析GPT

既存システムの保守で一番つらいのは、仕様書が古い、または存在しないことです。

そんなとき、ソース解析GPTを作っておくと便利です。

できることは以下です。

  • メソッドの役割を説明
  • 処理フローを文章化
  • DBアクセス箇所を抽出
  • 影響範囲を推測
  • 例外処理を確認
  • 改修時の注意点を整理
  • コメント不足箇所を指摘
  • 仕様書のたたき台を作成

特にレガシーシステムの現場では、これは強力です。

「このソース、結局何をしているの?」
「この改修、どこまで影響する?」
「設計書に戻すならどう書く?」

こういった調査を、マイGPTにまず整理させることで、初動がかなり早くなります。


3. テスト観点洗い出しGPT

テスト設計は、経験差が出やすい仕事です。

ベテランなら自然に見える観点も、若手には見えません。

そこでテスト観点GPTを作ります。

あなたは業務システムのテスト設計に強いQAエンジニアです。
入力された仕様をもとに、以下を出してください。

1. 正常系テスト
2. 異常系テスト
3. 境界値テスト
4. 権限別テスト
5. データ不整合テスト
6. 排他・同時実行テスト
7. 運用観点
8. 回帰テスト観点

表形式で、テスト観点・確認内容・期待結果・優先度を出してください。

これは新人教育にも使えます。

「なぜその観点が必要なのか」まで説明させると、単なる作業ではなく、テスト設計の勉強にもなります。


4. 障害報告整理GPT

障害対応では、技術力だけでなく説明力が問われます。

原因は何か。
暫定対応は何か。
恒久対応は何か。
影響範囲はどこか。
再発防止策は何か。
お客様にどう伝えるべきか。

ここを雑にすると、技術的には解決していても信頼を落とします。

障害報告GPTには、以下のように設定します。

あなたは顧客向け障害報告に強いプロジェクトマネージャーです。
入力された障害メモをもとに、以下の形式で整理してください。

1. 発生事象
2. 影響範囲
3. 原因
4. 暫定対応
5. 恒久対応
6. 再発防止策
7. 顧客向け説明文
8. 社内向け補足
9. 追加で確認すべき事項

専門用語は必要に応じて補足し、顧客が不安にならないように、誠実かつ分かりやすく書いてください。

これがあると、障害対応後の報告品質が安定します。


5. お客様向け説明GPT

SEは技術を説明できなければなりません。

しかも、相手が技術者とは限りません。

業務部門、管理職、役員、営業、サポート担当など、相手によって説明の粒度を変える必要があります。

お客様向け説明GPTでは、次のようにできます。

あなたは業務システム開発に詳しく、非エンジニアにも分かりやすく説明できるSEです。
入力された技術内容を、以下の3段階で説明してください。

1. エンジニア向け
2. 情シス向け
3. 業務部門・非エンジニア向け

難しい専門用語は避け、必要な場合は短く補足してください。
相手が判断しやすいように、メリット・リスク・判断ポイントも整理してください。

これは商談、要件定義、仕様確認、障害説明、追加提案で非常に使えます。


6. 議事録・課題管理GPT

会議後に議事録を書くのが遅い現場は多いです。

しかし議事録が遅いと、認識ズレも対応漏れも増えます。

マイGPTで以下を自動整理します。

  • 決定事項
  • 未決事項
  • 課題
  • 担当者
  • 期限
  • 次回確認事項
  • リスク
  • 顧客確認が必要な点
あなたはシステム開発プロジェクトのPMOです。
入力された会議メモをもとに、以下の形式で議事録を作成してください。

1. 会議概要
2. 決定事項
3. 未決事項
4. 課題一覧
5. 担当者
6. 期限
7. リスク
8. 次回までの宿題
9. 顧客確認事項

曖昧な内容は「確認が必要」と明記してください。

これだけでもプロジェクトの進行が変わります。


7. 若手育成GPT

意外と効果が大きいのが、若手育成用のGPTです。

たとえば、若手が質問した内容に対して、すぐ答えを出すのではなく、

  • まず何を確認すべきか
  • どこを調べるべきか
  • なぜそう考えるべきか
  • どう報告すればよいか
  • どこまで自分で考えるべきか

を返すGPTです。

あなたは若手エンジニアを育成するシニアSEです。
質問に対して、すぐに答えだけを出すのではなく、以下の順番で返してください。

1. まず確認すべきこと
2. 調査の進め方
3. 考えるべき観点
4. よくある落とし穴
5. 回答例
6. 上司や顧客への報告例

相手を責めず、成長につながるように前向きに説明してください。

これはかなり使えます。

なぜなら、若手が「答えをもらう人」ではなく、
考え方を学ぶ人になれるからです。

マイGPTを作るときに一番大事なこと

マイGPT作成で一番大事なのは、
何をさせたいかではなく、どんな成果を出したいかを決めること
です。

これはシステム開発と同じです。

悪い例:

設計書を作るGPT

良い例:

業務システムの基本設計書を、若手SEでもレビューに出せる品質まで引き上げるGPT

悪い例:

コードレビューするGPT

良い例:

Java/Spring Bootの業務アプリに対して、保守性・例外処理・トランザクション・SQL性能・セキュリティ観点で一次レビューするGPT

悪い例:

議事録を作るGPT

良い例:

要件定義会議の内容を、決定事項・未決事項・課題・担当・期限に整理し、次回会議でそのまま使える議事録にするGPT

目的が曖昧だと、出力も曖昧になります。

逆に、目的が明確だと、マイGPTは一気に実務で使える道具になります。

マイGPTの基本設計テンプレート

マイGPTを作るときは、以下のテンプレートで考えると作りやすいです。

# 役割
あなたは〇〇に強い△△です。

# 目的
このGPTの目的は、〇〇を実現することです。

# 対象ユーザー
主な利用者は〇〇です。

# 入力される情報
ユーザーからは、主に以下の情報が入力されます。
- 〇〇
- 〇〇
- 〇〇

# 実行すること
入力内容に対して、以下を行ってください。
1. 〇〇
2. 〇〇
3. 〇〇

# 出力形式
必ず以下の形式で出力してください。
- 〇〇
- 〇〇
- 〇〇

# 注意点
- 不明点は推測せず「確認が必要」と書く
- 顧客向け表現では専門用語を減らす
- 重要度が高いものから順に出す
- 実務でそのまま使える粒度にする

ポイントは、
役割・目的・入力・処理・出力・注意点を分けること
です。

これは設計書と同じです。

AIに対する指示も、曖昧なままだとバグります。

SEがマイGPTを使うときの注意点

便利だからこそ、注意点もあります。

1. AIの出力を正解扱いしない

マイGPTは強力ですが、最終判断は人間が行うべきです。

特に以下は注意です。

  • セキュリティ
  • 契約
  • 個人情報
  • 障害報告
  • 仕様確定
  • 本番作業
  • 顧客向け回答

AIは補助者であり、責任者ではありません。

SEとしての責任は、自分にあります。


2. 機密情報を安易に入れない

ソースコード、顧客情報、個人情報、契約情報などは、会社のルールに従って扱う必要があります。

OpenAI公式でも、GPTが外部APIやアプリと連携する場合、入力の一部が第三者サービスに送られる可能性があるため、信頼できるものだけを使うよう説明されています。(OpenAI Help Center)

会社で使う場合は、必ず社内ルールを確認しましょう。


3. “楽をする”ではなく“価値を上げる”ために使う

ここが一番重要です。

AIを使う目的は、手を抜くことではありません。

設計品質を上げる。
レビュー漏れを減らす。
若手の成長を早める。
顧客説明を分かりやすくする。
障害対応の信頼を高める。
チームのナレッジを共有する。

つまり、成果を上げるために使う のです。

エンジニアにとって本当に大事なのは、
「AIでどれだけ楽できるか」ではなく、
「AIでどれだけ顧客価値を上げられるか」です。

マイGPTは、SEの仕事を奪うのか?

結論から言うと、
ただ作業だけをしているSEの仕事は、確実に変わります。

しかし、価値を考えられるSEの仕事は、むしろ広がります。

なぜなら、マイGPTを使えば、以下のような仕事にもっと時間を使えるからです。

  • 顧客の本当の課題を考える
  • 仕様の背景を理解する
  • より良い設計を考える
  • チームの生産性を上げる
  • 若手を育てる
  • 提案の質を高める
  • 新しいサービスを考える
  • 属人化を減らす
  • 組織として成果を出す

AIに置き換えられるのは、
「考えなくてもできる作業」です。

AIで強くなるのは、
「考えて価値を生む人」です。

まとめ

マイGPTは、単なる便利機能ではありません。

SEにとっては、
自分の仕事の型を言語化し、再現可能な仕組みに変える技術
です。

設計、レビュー、テスト、議事録、障害報告、顧客説明、若手育成。
これらをマイGPT化できるエンジニアは、個人の生産性だけでなく、チーム全体の成果を変えられます。

これからのSEに必要なのは、
AIに質問する力だけではありません。

AIに業務を任せられる形に設計する力。
AIの出力を判断する力。
AIを使って顧客価値を高める力。

この3つです。

そして、これはまさにシステムエンジニアの本質です。

要件を整理し、
目的を定義し、
処理を設計し、
出力を確認し、
運用できる形にする。

マイGPT作成は、まさにSEの仕事そのものなのです。

最後に

エスプリフォートは、AIをただ流行りものとして扱う会社ではありません。
AIを使って、顧客価値をどう高めるか。
仲間の成長をどう支えるか。
仕事をもっと面白く、もっと意義あるものにできるか。
そこに本気で向き合う会社です。

私たちは、技術だけを見る会社ではありません。

「できない理由」ではなく「できる方法」を考える人。
仲間と協力し、顧客に向き合える人。
新しい技術を、自分の成長と会社の価値に変えたい人。
ただの作業者ではなく、価値を創るエンジニアになりたい人。

そんな人と一緒に働きたいと考えています。

AI時代は、怖がる時代ではありません。
むしろ、エンジニアがもっと面白くなる時代です。

あなたの技術を、もっと人の役に立つものに。
あなたの経験を、もっとチームの力に。
あなたの仕事を、もっと誇れるものに。

エスプリフォートで、AIを使う側から、
AIで価値を創る側へ進みませんか。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?