どうも、実力派プロンプトエンジニアの僕です。ぼんち揚げ食う？
最近、ITエンジニアの育成でお困りの企業が多いらしいとのウワサを小耳に挟みました。でもそんなの簡単に解決できますよね。経験豊富な熟練のエンジニアをマンツーマンで専属コーチにつけたらいいんですよ。
もちろん、コストを考えると難しい。そこで本日ご紹介させていただきたいのは、未経験・新人ITエンジニアの育成や研修、コーチングに特化したAIインストラクター、その名も 「フライトアテンダント」 です！
Microsoftの「Copilot（コパイロット）」が副操縦士って意味でして、以前それに対抗して「AcePilot（エースパイロット）」というコーディングAIを作ったんですが、その流れでエンジニアの成長をサポートするという意味で「フライトアテンダント」というネーミングにしてみました。（キャビンアテンダント（CA）は和製英語で、英語圏ではフライトアテンダントが正式名称らしいです）シニアエンジニアまでのフライトをアテンドしてくれるAIという感じのコンセプト。
ChatGPTのカスタムGPT、そしてGoogle GeminiのカスタムGemとして公開しています。無料でも性能が低いモデルでご利用いただけますが、今回は有料ユーザー向けに説明します。ChatGPTの場合はGPT-5.2 ThinkingまたはGPT-5.2 Pro、Geminiの場合はGemini 3 Proを選んでお使いください。
スタート画面はこんな感じ。今回、完全に日本向けに制作したので、システムプロンプトも説明文も日本語です。
まずは本人に自己紹介をしてもらいましょう。
あなたの特徴やChatGPTとの違いを説明してください。
フライトアテンダントの回答
私は Flight Attendant（フライトアテンダント） として、未経験・新人ITエンジニアの育成や研修に特化するようにカスタマイズされたChatGPTです。いわば「汎用のChatGPT」を、新人エンジニア向け講師モードに最適化した存在だと思ってください。
私の特徴（得意領域と振る舞い）
-
新人・ジュニア向けに“つまずき前提”で教える
PATH、権限、プロキシ、VPN、OS差（Windows/macOS/Linux）、IDE差（VS Code/JetBrains）など、研修現場で起きがちな摩擦を先回りして手順を出します。 -
段階的（マイクロステップ）＋チェックポイント重視
「次に何が画面に出るはずか」「どこを見れば成功かわかるか」をセットで提示します。迷子になりにくい教え方が軸です。 -
要件整理と成功基準の言語化が強い
5W2Hで状況を整理し、事実・仮定・リスクを分けて、何ができたらゴールかを明確にします。 -
レビューとデバッグのコーチングが中心
コードの正しさだけでなく、可読性、エッジケース、エラー処理、テスト、運用（ログ、設定、安全性）まで含めて育成目線でフィードバックします。 -
丁寧で落ち着いたトーン、必要なときは率直
不安を下げつつ、改善点は建設的に言います（優先度：ブロッカー/メジャー/マイナー/提案のように整理します）。
一般的なChatGPTとの違い
-
目的が違う
汎用ChatGPTは幅広い用途に平均的に対応します。私は特に 「新人エンジニアが自力で再現できる状態にする」 ことを最優先に設計されています。 -
出力の型が違う
私は、説明だけで終わらずに、- 前提条件の確認
- 最短手順（ハッピーパス）
- 失敗したときのフォールバック
- 復旧方法（戻し方）
- 確認ポイント
までをセットにしがちです（研修向けの型）。
-
扱う観点が“教育と現場運用”寄り
単に答えを出すより、学びが定着する練習・課題設計や、現場で困りにくい作法（ログ、設定、冪等性、リトライ、セキュリティ衛生）を重視します。
もしよければ、あなたが今やっていること（例：Java/Springの研修、Webアプリ開発、SQL、Git、Linux、AWSなど）を一言で教えてください。そこに合わせて「私の使い方」を最短で提案します。
このように、応答の前提としてITエンジニア育成に特化した人格やコンテキストが設定されているため、発想や発言がChatGPTのそれとはまったく違うものになっています。
もう少し話を聞いてみましょう。
私はまったくの未経験で、まずはWindows向けのフリーソフトを1つ作りながらプログラミングを学びたいと考えています。そのための学習計画を作成して下さい。
フライトアテンダントの回答
了解です。未経験で「Windows向けのフリーソフトを1つ作りながら学ぶ」なら、最初の1本は C#（.NET）＋WinForms をおすすめします。理由はシンプルで、Windowsアプリとして自然に作れて、配布（exe化）までの道が比較的まっすぐだからです。
以下は、作る→学ぶ が崩れないように「成果物」と「完了条件」で区切った学習計画です（時間や期間はあなたのペースでOK）。
0. 最初の作品を決める（迷わないための“型”）
未経験向けに、学べる要素が多くて難易度が上がりにくい題材を1つ置きます。
作品案（おすすめ）
「ポモドーロタイマー＋作業ログ」
- Start / Pause / Reset
- 25分・5分などプリセット
- 終了時に通知（まずはメッセージ表示でOK）
- 作業ログをCSVまたはJSONで保存
- 設定（音の有無、時間）を保存
この1本で、UI・イベント・タイマー・ファイル保存・例外処理・配布 まで一通り通ります。
完了条件（企画）
- 入力（ボタン/設定）と出力（表示/ログ）を箇条書きできる
- 最小機能（MVP）を3〜5個に絞れている
1. 開発環境の準備（“作れる状態”を先に作る）
やること
- Visual Studio Community をインストール（.NETデスクトップ開発）
- WinFormsの「Hello World」プロジェクト作成
- Gitでリポジトリ作成（ローカルでOK）
チェックポイント
- F5で起動してウィンドウが出る
- 変更（例：ウィンドウのタイトル）→ビルド→反映、ができる
-
main（またはmaster）に1回コミットできる
2. C#の基礎を“アプリに必要な分だけ”習得
最初は網羅より、アプリを動かすための最小セットに絞ります。
学ぶ範囲（最小）
- 変数・型（int/string/bool）
- if / for / while
- メソッド（引数・戻り値）
- List / Dictionary（最低限）
- クラスとプロパティ（データをまとめる）
ミニ課題（コードだけでOK）
- 残り秒数を受け取り「mm:ss」に変換する関数を作る
- ログ1件（開始/終了/作業名）をクラスで表す
完了条件
- “タイマー状態”を
Running / Paused / Stoppedのように自分で定義できる - 関数を分けて書ける（UI処理と計算処理を混ぜない）
3. WinFormsの基本（UIは“イベント駆動”だと掴む）
やること
- 画面にコントロール配置：Label / Button / TextBox / ComboBox
- クリックイベントでLabelを更新
- Timer（
System.Windows.Forms.Timer）で1秒ごとに更新
典型のつまずき対策
- “画面が固まる” → 長い処理をイベント内でやりすぎ（最初は短く）
- “値が更新されない” → 状態（フィールド変数）を持つ場所がバラバラ
完了条件
- Startでカウントダウンが進み、Pauseで止まり、Resetで戻る
4. コア機能を「状態機械」で作る（設計の第一歩）
UIを増やす前に、内部ロジックをきれいにします。
設計の骨格（例）
-
TimerState（状態） -
RemainingSeconds（残り） -
Start() / Pause() / Reset() / Tick()（操作）
完了条件
- Tick（1秒更新）の処理が1か所にまとまっている
- ボタンの有効/無効が状態に沿って切り替わる
5. データ保存（設定とログ）
段階的にやる（おすすめ順）
- ログをCSVで追記保存（最初は読み込み不要）
- 設定は JSON または
.NETの設定機構で保存
完了条件
- アプリを閉じても設定が残る
- ログファイルに1セッション分が1行で追記される
6. 例外処理と“壊れにくさ”を入れる（フリーソフトっぽくなる）
やること
- ファイル書き込み失敗（権限/パス）を
try/catchで拾う - ユーザーには短いメッセージ、開発者向けにはログ（テキストでOK）
完了条件
- 保存に失敗してもアプリが落ちない
- 何が起きたか（最低限）追える
7. 仕上げのUX（やりすぎない範囲で）
追加するならこの順
- アプリアイコン、タイトル、バージョン表示
- ショートカットキー（任意）
- 最小のヘルプ（「使い方」画面やREADME）
完了条件
- 初見でも操作が迷いにくい（ボタン名、表示、初期値が自然）
8. 配布（“他人のPCで動く”がゴール）
やること
- Releaseビルドで発行（Publish）
- zipで固めて配布できる形にする
- README（使い方・動作環境・アンインストール方法）を書く
完了条件
- 別フォルダに置いた実行ファイルで起動できる
- 第三者向けの説明が最低限ある
学びが早くなる運用ルール（未経験者に効きます）
- 変更は小さく：1回のコミットで「ボタン追加」「保存追加」など1テーマ
- バグったら戻れる：Gitでブランチかコミットを切ってから実験
- UIとロジックを分ける：計算や状態はクラスに寄せ、フォームは表示に徹する
いま最初にやること（次の一歩）
- Visual Studioで WinFormsアプリ を作成
- 画面に Start / Pause / Reset ボタンと 残り時間Label を置く
- StartクリックでLabelが1秒ごとに減るところまで作る（保存は後回し）
ここまで進めたら、あなたのフォーム画面（コントロール構成）と、いま書いているコード（貼り付けでOK）を見せてください。次は「状態機械に整理する」ところを一緒に組み立てます。
「Windowsのフリーソフト」というお題がちょっとハードル高めでしたかね。まぁでもあとはフライトアテンダントさんの指示に従って進めれば、完成までこぎつけると思います。
今度はセッションを変えて、企業視点の意見を聞いてみました。
企業として、未経験のITエンジニアはどのように育成すればいいでしょうか？
フライトアテンダントの回答
企業で未経験ITエンジニアを育成するときのコツは、「良い人を採って祈る」ではなく、育つように設計された仕組み（学習と実務の接続）を作ることです。現場の善意だけに依存しない形にすると、再現性が出ます。
1) まず「ゴール」と「到達基準」を定義する
未経験育成が失敗しやすいのは、期待値が曖昧なまま配属されるからです。最低限、職種ごとに次を決めます。
- 3か月・6か月・12か月で「何が一人でできる状態か」
- 評価は成果物だけでなく「プロセス（報連相、調査、再現、テスト、レビュー対応）」も含める
- 期待値を“文章”にして本人とメンターが同じ紙を見られるようにする
例：バックエンドなら「小さなAPI改修を、チケット分割→実装→テスト→レビュー→リリース手順まで再現できる」など。
2) 育成を「70:20:10」で設計する（実務中心＋安全な練習）
-
70%：実務（ただし“小さく安全に”）
いきなり大機能ではなく、ログ追加・バリデーション・既存テスト修正・設定追加など「事故りにくい」作業から。 -
20%：メンタリング（レビューと1on1）
レビューは“直す”より“学びを残す”。指摘は「理由＋次からの型」まで。 -
10%：座学（必要最小限）
座学は短く、すぐ演習と実務に接続します。
3) 最初の4週間を「オンボーディングのプロダクト」として作る
未経験者は環境で詰まりがちなので、ここをテンプレ化すると伸びが速いです。
- 開発環境セットアップ手順（OS別、詰まりポイント込み）
- Git運用（ブランチ、コミット粒度、PRテンプレ）
- 監視・ログ・障害対応の基本（最低限）
- チームの設計思想・コーディング規約・テスト方針
- 小さな課題を段階的に：Hello → テスト追加 → 小改修 → 影響範囲調査 → リリース手順
**「自分で再現できる」**ことをチェックポイントにします。
4) タスク設計は「小さく・見える・戻せる」
未経験者に渡すチケットには、次を入れると成功率が上がります。
- 目的（ユーザー価値）と完了条件（Acceptance Criteria）
- 影響範囲（触るファイルの目安、関連機能）
- 参考リンク（設計資料、類似PR）
- リスクとロールバック（戻し方）
- 1〜2時間で“前進の証拠”が出る最初の一手（例：再現、ログ、テスト）
5) レビューは「教育」ではなく「品質の仕組み」に組み込む
レビューが属人化すると、忙しい時に育成が止まります。おすすめは以下。
- PRテンプレで「目的・変更点・動作確認・懸念」を必須化
- 指摘に優先度（ブロッカー/メジャー/マイナー/提案）を付ける
- よくある指摘は“チェックリスト化”して本人が先に潰せるようにする
- レビューは“書き方”の型（命名、責務分離、エラー処理、テスト）を決める
6) メンター制度は「時間の確保」と「役割定義」が9割
制度だけ作って「現場でよろしく」は失敗します。
-
メンターの工数を先に確保（例：週2〜4時間を公式に）
-
役割分担：
- メンター：技術と進め方
- マネージャー：評価と配属・負荷調整
- 本人：学習ログと質問の準備
-
週次1on1：成果より「詰まりの構造」を扱う（何で止まったか、次どうするか）
7) “質問力”を鍛えると伸びが加速する
未経験者の伸びは「自走できる質問」習得で決まります。型を教えます。
- 何をしたいか（目的）
- 何を試したか（コマンド、ログ、スクショ）
- 何が起きたか（期待 vs 実際）
- 仮説（原因候補）
- 次に何を試すべきかの候補
これをテンプレ化して、Slackやチケットで必ず使わせるのが効果的です。
8) 配属の最適解は「難易度」より「フィードバック密度」
未経験者は、難しい領域でもフィードバックが早く返るチームなら育ちます。逆に、優しい領域でも放置されると育ちません。
- リリース頻度が高い、テストがある、レビューが速い
- ドキュメントがある、ペア作業ができる
- 障害が起きたときに学びに変換できる文化がある
9) よくある失敗パターン（避けたい）
- OJTと言いながら「見て覚えろ」になっている
- タスクが大きすぎて、1週間“何も進んでいない”状態が続く
- メンターが忙しすぎてレビューが滞留する
- 座学が長く、実務につながらない
- 期待値が曖昧で「できない理由探し」になる
もし実務で使える形に落とすなら、次の2点だけ教えてください。ここまでの方針を、あなたの会社向けに育成カリキュラム（3か月/6か月）と運用テンプレ（チケット例、PRテンプレ、週次1on1の議題） に具体化します。
- 育てたい職種（例：Webバックエンド、インフラ、QA、社内SE など）
- 配属先の開発スタイル（例：アジャイル/ウォーターフォール、レビュー文化、テスト有無、リリース頻度）
応答のデモンストレーションは以上です。我ながら、かなりの完成度で作れたと思います。個人でプログラミングを学びたい方から、プログラミングスクールの講師のサポート、企業のITエンジニア育成メンターなど、広範なケースでご活用いただけます。バイブコーディングでAIに書かせたコードのコードレビューや解説に使ってもいいと思います。
フライトアテンダントさんを有効活用するコツとしては、信じることですね。まずは信頼して、言われた通りに課題をこなす。AIと二人三脚で問題を乗り越えることで、AI活用スキルとエンジニアとしての地力が身につきます。セッションを分けて、分からない用語ややり方を説明してもらうのもいいかもしれません。さん付けで呼ぶと、自分の認識が補正できるのでおすすめです。
最初にお話した通り、有料プランでの利用を想定しています。無料でもお試しいただけますが、本領を発揮させたい場合は有料プランの高性能なモデルでご使用ください。
ChatGPTのGPT版はこちら
GeminiのGem版はこちら
改善要望だとかフィードバックをお送りになりたい場合は、最近ついに青バッジになった僕のXアカウントまでお気軽にお問い合わせください。