社会人が生成AIを学ぶ順番｜業務で使えるまでに必要だったこと

生成AIを「とりあえず試す」段階から、仕事の中に組み込んで「実際に使えている」状態になるまで、私はいくつかのステップを踏む必要がありました。ツールの操作を覚えること自体は比較的早くできましたが、業務で責任を持って使えるようになるまでにはそれなりの時間がかかっています。

この記事では、インフラエンジニアとして生成AIを業務に取り込んでいく過程で実際に踏んだ手順と、使えると判断した場面・使わなかった場面を整理します。スクールに通った経験はなく、あくまで実務の中で試行錯誤した範囲の話です。そのことを念頭において読んでください。

「使っている」と「業務で使えている」の違い

最初に整理しておきたいのは、この2つの状態の違いです。

「使っている」は、個人で質問してみたり、調べものや雑談的な用途に触れたりしている状態です。「業務で使えている」は、仕事のアウトプットを出すプロセスの中にAIが実際に組み込まれている状態です。この2つには明確な差があります。

個人利用であれば、出力が多少ずれていても大きな問題にはなりません。業務に組み込む場合は、その出力を使った結果が仕事の品質に影響します。つまり出力の正誤を自分で評価できることと、使える場面と使えない場面を判断できることが前提として必要になります。

この前提なしに「業務で使う」に進もうとすると、うまくいかない場面が出てきたときに「AIは使えない」という結論に飛びやすくなります。逆に前提を先に整えると、使える範囲が着実に広がっていく感覚がつかめます。

私が経験したステップを順番に書くと、次のようになります。

1. ツールに慣れる（触って出力を受け取る経験を積む）
2. 出力のばらつきを体感で理解する
3. プロンプトの書き方を整理する
4. 業務のどこに挟めるかを見つける
5. 出力を検証する習慣をつける
6. 情報の取り扱いの基準を決める

1と2は比較的早く進みます。3から6が実質的な関門で、それぞれに意識的に取り組まないと止まる場所です。

ステップ1と2 ─ 出力のばらつきを知る

最初にやったのは、同じ質問を繰り返してみることでした。

たとえば「このシェルスクリプトでこういうエラーが出た。原因と対処法を教えて」という内容で、同じ状況を説明して何回か聞いてみると、返ってくる答えは毎回少しずつ違います。根本的に外れているわけではないが、強調している部分が変わっていたり、示すコマンドのバリエーションが変わっていたりします。

これは生成AIの出力の性質によるものです。確定的な正解を返すのではなく、文脈から確率的に「ありそうな回答」を生成します。このことを最初に体感で理解しておくと、後の判断がだいぶ楽になります。

理解していないと、最初に正しい答えが出たときにそれを盲信し、次に違う答えが出たときに混乱します。理解していれば、「今回の出力はこの方向で書かれているが、別のアプローチも考えられる」という読み方が自然にできます。

インフラ系の作業でこの性質が問題になりやすいのは、コマンドの正確さが求められる場面です。手順の流れは正しくても、コマンドのオプションがバージョン違いで変わっていたり、存在しないフラグが混じっていたりすることがあります。コードや手順書にそのまま使う前には必ず検証を挟む必要があります。

生成AIが特に誤りやすい場面も把握しておくと、使い方が安定します。最近の出来事や新しいバージョンの情報は学習データに含まれない場合があり、古い情報を正しいものとして返すことがあります。自社環境に固有の設定や特定の構成に依存した詳細判断も苦手で、一般的な答えを返してくることが多い。こうした苦手領域を理解した上で、補完や検証の方法を考えるのが現実的な使い方です。

ステップ3 ─ プロンプトの書き方を整理する

出力のばらつきに慣れてきた段階で、次に意識したのはプロンプトの書き方です。書き方によって出力の質が変わることが分かってきました。

試行錯誤の末に落ち着いたのは、次の3点を意識した書き方でした。

文脈と役割を先に書く

「あなたはLinuxサーバの運用経験があるシニアエンジニアとして回答してください」のように、回答者の立場を先に設定してから質問する方法です。基礎的すぎる説明が省かれたり、実務上の観点が入ったりすることが増えました。設定した役割を完全に信頼するべきではなく、あくまで出力の傾向を変える手段として使っています。

タスクと出力形式を明示する

「要約してください」より「以下のログを読んで、エラーが発生した時刻と推定される原因を箇条書きで3点以内にまとめてください」のほうが、使いやすい形で返ってきやすい。特にインフラ系の作業では、「ステップごとのコマンド形式で書いてください」「前提条件を先に書いてから手順を書いてください」のように、出力形式を具体的に指定すると安定度が上がります。

不要な内容を除外するよう指示する

「一般的な背景説明は省略して、実行可能なコマンドだけ書いてください」のように、不要な部分を削る指示を入れると、長すぎる回答を受け取らずに済みます。文脈が明確な作業では「既知の情報として扱って、実装部分だけ答えてください」という形の指示が有効でした。

ただし「プロンプトさえうまく書けば何でもできる」という発想になりすぎることには注意が必要です。AIの限界はプロンプトの工夫で消えるわけではなく、苦手な領域はどんな書き方をしても変わりません。プロンプトの工夫は、AIが答えられる範囲の中での精度調整と考えるのが適切だと思っています。

ステップ4 ─ 業務のどこに挟めるかを探す

プロンプトの書き方を覚えたあとで、次の課題が来ました。実際の仕事の流れのどの部分に使えるのかという判断です。使える場所は意外に限られていて、合わない場所に使おうとすると返って手間が増えることもありました。

実際に使えると判断した場所

手順書のたたき台作成が、最初に「使える」と感じた場面です。定型的な作業の手順書を一から書くのは時間がかかります。特に似た作業が定期的にある場合、毎回同じような構造を作り直すのは非効率です。

私がやっていたのは、「この作業の概要」「実施するステップの骨格」「注意事項の見出し」だけをAIに伝えて、文章の構造を出力させる方法です。実際のサーバ名・IPアドレス・設定値などの固有情報は手動で埋める。AIに渡すのは汎化した情報だけなので、社外サービスへの入力リスクも限定できます。出てきた構造を確認して、不足している観点を足したり、並び順を直したりして完成させます。

ログの要約と傾向把握も使いました。大量のログをそのまま読もうとすると時間がかかります。重要な行を抽出して整形してからAIに渡し、「このログを読んで、異常と思われるパターンを説明してください」と聞く形です。渡す前に、IPアドレス・ホスト名・ユーザ名などの固有情報は置換するか削除します。出てきた「分析結果」は参考として扱い、最終的な判断は自分でしています。

スクリプトの下書きは、慎重に使っています。「指定した条件のクラウドリソース一覧をCSVに出力するスクリプトを書いて」という形で下書きを出してもらい、中身を自分で読んで理解したうえで使います。全部を信じてそのまま動かすのではなく、「何をしているコードか」を把握した状態で使うルールにしました。コードレビューの要領で読んで、問題がなければテスト環境で実行する手順を踏んでいます。

メールや報告の文案も使っています。「こういう内容を、こういう相手に伝えるためのメール文案を書いてください」という形で下書きを出してもらい、そこから書き直す形です。ゼロから書き始めるよりも、叩き台があるほうが速く仕上げられます。機密性の高い内容が含まれる場合は対象外としています。

会議後のメモ整理も、限定的に使っています。公開情報の範囲でまとめを書いてもらう使い方です。具体的な顧客名・内部の方針といった情報は含まない内容に限定しています。

使えなかった・使わなかった場所

最終判断が必要な局面には使いません。障害対応のエスカレーション可否、設計方針の決断、リスク評価の判断など、自分が責任を持つ意思決定をAIに委ねることはしていません。参考意見として聞くことはありますが、最終的な判断は自分でしています。

顧客環境の情報を含む作業も原則対象外にしました。顧客名・顧客のシステム構成・具体的な設定情報を公開型のAIサービスに入力することは、情報管理の観点から慎重に判断する必要があります。

ステップ5 ─ 出力を検証する習慣をつける

この段階が、「試している」から「使えている」への実質的な関門だと感じています。

生成AIの出力には、一見正しそうに見えて実際は誤りが含まれることがあります。技術的な内容では、バージョンが古い情報に基づいたコマンドが出てきたり、存在しないオプションが書かれていたりします。説明文では事実関係の誤りが含まれることがあります。特に急いでいるときほど確認をはしょりたくなりますが、そこを省略したときに問題が起きやすいことを経験で学びました。

私が取り入れた検証のルールは次のとおりです。

コードは必ずテスト環境で実行してから使う。 本番環境で直接実行したことは一度もありません。テスト環境で期待した動作をするかを確認してから、必要に応じて本番に移します。この手順はAI生成のコードに限らず新しいスクリプトを使う際の基本ですが、AI生成の場合は特に意識して守っています。

手順書は各ステップを自分で追う。 AIが出した手順を鵜呑みにせず、それぞれのステップが意味することを自分で理解してから組み込みます。「設定の変更前後でサービスへの影響はないか」「前後のステップとの整合性はあるか」という観点で確認します。

出典が確認できないものは明記する。 「〜という仕様です」という説明が出てきたとき、公式ドキュメントで確認できるかどうかを確かめます。確認できたものはそのまま使い、確認できないものは「要確認」とメモして後から調べます。

この検証習慣が定着すると、自然と「検証コストに見合うかどうか」でAIの使いどころを判断するようになります。たたき台の作成や定型的な文章整形は検証コストが低いので積極的に使い、設定変更の手順や詳細な技術判断は検証コストが高いので慎重に使う、という使い分けが機能するようになります。

ステップ6 ─ 情報の取り扱い基準を決める

業務で生成AIを使う中で、一番慎重に判断したのが入力情報の取り扱いです。これを整理せずに使うと、後から「これは入力してよかったのか」という問題が出てきます。

私が決めているルールはシンプルで、「外部の人間に見せることができない情報は、外部サービスにも入力しない」というものです。

具体的に入力しないのは次の種類の情報です。

• 顧客名・顧客のシステム名・顧客のIPアドレスやドメイン
• 自社のシステム名・内部ホスト名・内部ネットワーク構成
• 社内限定の設計書や仕様書の記載内容
• 特定のインシデントや障害の詳細情報
• 個人を特定できる情報

代わりにやること：「Azure上のVMがhogehoge-server-01で…」という具体的な記述を、「クラウド環境上のVM1台で…」という一般化した形に置き換えてから質問します。手間は少しかかりますが、情報管理のリスクを下げながらAIを使う方法として定着しています。

固有名詞を置き換えて一般化する習慣をつけると、「この質問を汎化するとどういう問題設定になるか」を考えるクセがつき、問題の本質を整理する力にもなります。最初は手間に感じますが、やっているうちに自然にできるようになります。

もう一点、組織のAIツール利用ポリシーを定期的に確認することが重要です。ポリシーの内容や利用可能なツールの範囲は更新されることがあります。個人の判断だけで運用しているうちに、気づかないうちに規則に違反した状態になっていることがあります。

業務での活用が広がるツールの種類

生成AIと一口に言っても、業務で使えるツールの種類は複数あります。それぞれが得意とすることが異なるため、用途に合わせて使い分けることが使い方を広げる近道です。

テキスト生成・対話型のAIは、ChatGPTやClaude、Geminiなどが代表的です。質問への回答、文章の下書き、コードの生成、要約など、テキスト入力に対してテキストで返すタイプです。私が業務でまず使い始めたのはこの種類で、手順書のたたき台やログの要約、スクリプトの下書きといった用途がここに含まれます。

コード補完・コード生成系のツールは、GitHub CopilotなどのIDEプラグインとして使えるものです。コードを書く場面でリアルタイムに補完が入るため、対話型より更に素早く使えます。ただしコード補完も生成AIと同様に、出てきたコードを自分で読んで確認する習慣が必要です。

音声・画像生成系のツールは、業務での利用場面が限定的ではありますが、図の作成・プレゼン資料の補助・音声コンテンツ作成などに使われることがあります。業務利用が許可されているかどうかの確認が特に重要です。

エージェント型のAIは、複数のタスクを連続して実行するタイプです。「ファイルを読み込んで、整形して、別のツールに渡す」という複数ステップの処理を一度の指示でこなせます。インフラ業務では運用自動化との相性がよく、今後の活用が広がる領域です。

これらのうち、私が業務で使い始めたのはテキスト生成・対話型からです。使い方の感覚をここで覚えてから、コード補完系に広げていく順番が、一度に複数を覚えるより混乱が少なく済みます。

体系的に学ぶ選択肢

実務の中で試行錯誤を続けてきましたが、「プロンプトエンジニアリングの体系的な整理」「AIツールを業務フローに本格的に組み込む方法論」「複数のAIツールの使い分け方」といった視点は、独学では整理しにくいと感じました。

体系的に学ぶ手段としては、書籍・公式ドキュメント・オンラインコース・勉強会やコミュニティなど複数あります。どの手段が自分に合うかは、過去に独学で技術を習得した経験があるかどうかや、学習に使える時間の量によって変わります。

コースを使う選択肢の一つとして、DMM 生成AI CAMP があります。公式サイトの説明を読む限り、ChatGPTをはじめとする生成AIを業務で活用することを目的としたコースです。無料セミナーが用意されているので、コースの内容や進め方を先に確認できます。自分の目的に合うかどうかをそこで判断するのが現実的です。受講費用は数十万円規模になりますので、必ず公式の料金表で確認してください。

スクールの費用が気になる場合は、教育訓練給付金や会社の研修支援制度などコスト面の選択肢をまとめたスクール費用を抑える方法も参考にしてください。

また、生成AIとPythonは組み合わせると活用の幅が広がります。スクリプトでAIのAPIを呼び出す、出力を加工する、繰り返し作業を自動化するといった使い方ができると、仕事の中に取り込める範囲が一気に広がります。PythonをインフラやクラウドのOps業務でどう使うかはいまPythonを学ぶ意味に書いています。

学習を続けるための習慣

実務に組み込んでからも、維持するために意識していることがあります。

ひとつは、うまくいったプロンプトを記録しておくことです。記録があると、次に似た作業をするときにそのまま使えます。改善した経緯も残しておくと、どういう修正が効いたかが分かります。チームで使うなら、有効なプロンプトを共有する仕組みを作ると、学習コストを全体で下げられます。

もうひとつは、ツールの変化を定期的に確認することです。生成AIのツールは機能の追加や変更が速い。半年前の使い方が最新のツールでは非効率になっていることがあります。新機能を把握して、業務フローを適宜更新する習慣が必要です。

AIツールを使いこなすための学習と、キャリアへの影響を考えるための勉強時間の確保については働きながら勉強時間を確保するに書きました。時間管理の具体的な方法を整理しています。

まとめ

生成AIを業務で使えるようにするまでの順番を振り返ると、次のように整理できます。

出力のばらつきを知る。 同じ質問に対して異なる回答が来ることを体験で理解します。これがないと、最初に正しい答えが来たときにそれを盲信する判断につながります。

プロンプトの書き方を整理する。 文脈の設定、タスクと出力形式の明示、不要な内容の除外。この3点を意識するだけで出力の安定度が変わります。

業務のどこに使えるかを探す。 手順書のたたき台・ログの要約・スクリプトの下書き・文案の整形など、検証コストが低い場面から始めます。最終判断が必要な場面や機密情報が含まれる場面は対象外にします。

出力を検証する習慣をつける。 コードはテスト環境で実行、手順は自分で追う、情報は出典を確認する。このルーティンが定着すると、AIを信頼しすぎないバランスが保てます。

情報の取り扱い基準を決める。 固有情報を一般化してから入力する習慣と、組織のポリシーの定期確認が基本です。

これらのステップを順番に踏むと、「触っている」段階を抜けて、実際の仕事の中にAIが組み込まれた状態に近づいていきます。

生成AIを業務で活用するスキルは、一度習得すれば固定されるものではなく、ツールの進化に合わせて継続的に更新していく性質のものです。特定のプロンプトが通用する期間、モデルの性能の変化、新しいツールの登場など、変化のスピードが速い領域であることを前提にして学習計画を立てることをおすすめします。インフラの仕事の中での生成AIの活用は、業務の生産性を上げる手段として実用的な可能性がある領域です。焦らず小さな試みから始めて、自分の仕事に合う使い方を積み上げていくアプローチが長続きします。