この記事は、私という一人の人間が、生成AIを「相棒」にして、一つのプロジェクトを成し遂げた記録です。
そして、実はこの記事そのものも、その「相棒」と一緒に書き上げました。
どこまでが私の経験と言葉で、どこからがAIの筆によるものか。そんな舞台裏も想像しながら、読み進めていただけると幸いです。
それでは、本編をお楽しみください。
はじめに：あなたの会社では、生成AI、みんな使えていますか？
「生成AIがすごいらしい」「業務が劇的に効率化するらしい」 そんな言葉が飛び交うようになって久しいですが、皆さんの職場では、どれくらいの人が日常的にAIを使いこなせているでしょうか。
私が働くAI利活用やDX推進を支援する会社でさえ、正直なところ、社員一人ひとりのAI活用レベルには大きな差があります。一部の社員がツールを使いこなして成果を上げる一方で、多くの人は「何から手をつければいいか分からない」と感じている。この「見えない壁」をなんとかしたい、そんな思いがありました。
そこで、社内向けの勉強会を企画することにしたんです。
ゴールは、難しい理論を学ぶことではありません。まずはツールに触れてもらい、「AIって、こんなに仕事が楽になるんだ！」という「業務効率化の実感」を一つでも持ち帰ってもらうこと。そんな思いで企画しました。そのためには、多くの社員が日頃から「面倒だな」と感じているであろう、定型的なデータ作業のような身近な課題を扱えると、より効果的ではないかと考えていました。
そして、どうせなら、その勉強会の準備自体を「生成AI」と一緒に行ったら、もっと面白くなるのではないか？と考えました。 この記事は、そんな思いつきから始まった、一人の社員が生成AIを「相棒」にして、生成AIの勉強会をゼロから作り上げた、リアルな奮闘の記録です。
【準備編】AIは魔法の杖か？いいや、最高の「相棒」だ
さて、ここからが勉強会の準備プロセスです。
私の最初の動機は、とてもシンプルなものでした。「せっかく生成AIの勉強会をやるんだから、その題材検討や教材作成もAIと一緒にやった方が面白いんじゃないか？」しかし、この素朴な好奇心は、すぐに「じゃあ、人間である自分は何をすべきなんだろう？」という、本質的な問いへと変わっていきました。
そこでまず私が「人間として」決めたのは、勉強会のゴール設定でした。
「テーマは、プログラミング初心者でも関心を持ちやすく、業務効率化を『自分事』として実感できるものでなければならない」
参加者の顔を思い浮かべながらゴールを設定する部分こそ、人間が担うべき役割だと考えたのです。
この方針を持って、私はAIという相棒に、最初の具体的なタスクを依頼しました。
Step 1: テーマ決め - 最初の相談相手は、AIでした
まず、Geminiに相談役をお願いしました。
「うちの会社の技術スタック（Pythonがメイン、データ関連業務多め）を考慮して、プログラミング初心者でも関心を持ちやすい勉強会のテーマを10個提案して」
Geminiとの壁打ちを重ねる中で、最終的に「ETL/データクレンジング」というテーマを選択しました。決め手は、特定の専門知識がなくても誰もがイメージしやすく、かつPythonで完結できるという汎用性の高さです。
Step 2: 教材（お題目）作成の舞台裏 - AI同士を連携させてみた
次に、ハンズオンの教材作り。ここでは、少し面白い連携プレーを試してみました。
-
[Gemini] 問題のアイデア出し
まずはGeminiに「データクレンジングでよく発生する品質問題のパターンをリストアップして」と、ブレスト相手になってもらいました。 -
[Github Copilot Agent] ダミーデータのスクリプト作成
次に、Github Copilot Agentに「さっきGeminiがリストアップした品質問題をすべて含んだ、リアルなダミーデータを生成するPythonスクリプトを作って」と依頼しました。
もちろん、最後は自分の目でしっかりレビューしましたが、ゼロから考える手間が省けただけでも、計り知れない価値がありました。
Step 3: 【仮説検証】AIに「新人開発者」のロールプレイをさせてみた
さて、ここが今回の準備で最も学びが深かった部分です。
開催者である私自身、「AIはどこまで自律的に開発プロセスをこなせるのか？」という明確な答えを持っていませんでした。そこで、一つの仮説検証を試みることにしました。それはAIに「新人開発者」の役割を与え、「分析→設計→実装」という一連の開発工程をどこまで任せられるかテストするというものです。
【第一段階：データ分析】
まず、Github Copilot Agentに汚れたデータファイルを与え、こう指示しました。
「まずはデータクレンジングに向けて、このデータの問題点を洗い出してください」
AIは、欠損値の存在、データ型の一貫性のなさ、表記揺れの可能性など、いくつかの的確な分析結果を返してくれました。ここまでは非常にスムーズです。
【第二段階：設計書の作成】
次に、その分析結果をもとに、こう指示します。
「ありがとう。では、いま洗い出した問題点を解決するための、データクレンジングコードの設計書を作成してください」
AIは、処理の流れや各ステップの目的をまとめた、なかなかしっかりとした設計書を提示してきました。（お、これは期待できるぞ…）と、この時点では思っていました。
【第三段階：実装と、厳しい現実】
そして、最後のステップです。
「この設計書に基づいて、Pythonコードを実装してください」
ものの数秒で、設計書に沿ったコードが生成されます。一見、完璧に見えました。 しかし、そのコードは、やはりそのままでは動きませんでした。
実行すればエラーで停止し、よく読めば設計書の一部を無視したロジックになっている。まさに仮説に対する「AIは設計まではできても、正確な実装はまだ苦手である」という明確な検証結果が得られた瞬間でした。
ここから、私とAIの地道なレビューと修正のプロセスが始まります。 「このコードはエラーになる。修正して」 「設計書と違う。このロジックだとこういうケースが考慮漏れだ」
このやり取りは、まるで「頭では理解しているけれど、実際に手を動かすとミスが多い新人プログラマー」に、粘り強くコードレビューをしているような感覚でした。AIの出力を鵜呑みにせず、設計書と照らし合わせながら、テストと修正を繰り返す。この泥臭いプロセスこそが、AIとのリアルな協業なのだと痛感しました。
【開催編】「泥臭いプロセス」を「再現可能なメソッド」へ
この泥臭い準備プロセスで得られた数々の失敗と発見は、私にとって大きな財産となりました。
そして、それらの学びを体系化し「誰でもAIとの協業を成功させるためのメソッド」として参加者に伝えることこそが、この勉強会の本当のゴールだと確信しました。
迎えた勉強会当日。私が伝えたかったのは単なるAIの機能ではなく、この試行錯誤の末に見つけた「リアルなAIとの付き合い方」でした。AIがコードを生成していく様子に、会場からは何度も「おぉ…」という声が上がります。
特に「要件定義⇒設計⇒実装」という上流工程からAIに壁打ちさせるテクニックは多くの方の「AIコーディング=いきなり実装」というイメージを覆すことができたようで、非常に手応えを感じた瞬間でした。参加者の方の驚きが、私にとっては大きな喜びでした。
勉強会後のアンケートには、嬉しい、そして身が引き締まるような声が詰まっていました。
有益だった点（一部抜粋）
- 「生成AIでコードがかけるらしいよ、とは理解していたものの、利用するうえでのプロンプトの工夫や、どういった点に気を付けなければならないのかといった点がよく理解できた。あまり普段はコードを書かないが、明日からでも利用できそうだと感じた。」
- 「要件定義⇒設計⇒実装 と進ませるテクニックが目からうろこでした。いきなり実装をするイメージでした。」
課題や懸念点（一部抜粋）
- 「AIの出力が期待通りでなかった際に、どのように対話を重ねて修正・改善してくか、具体的な手順が知りたかった。」
- 「生成されたコードをAI自身に解説させながら理解を深めるには、どのような指示を出せば良いのか知りたかった。」
- 「あくまで自分が開発できることに対しての「自動化や支援」の位置づけとする必要があること、分からずに使ってそれを納品してしまう怖さを感じました。」
まとめ：AIとの協業で見えた、これからの働き方
準備編で、私は「AIと協業する上で、人間である自分は何をすべきか？」という問いにぶつかったと書きました。この一連の挑戦を通して、その答えが明確に見えました。
「AIに何をやらせ、人間が何を意思決定するのか」という役割分担、「メタ設計」こそが、人間が担うべき最も重要なタスクだったのです。そして、今回の挑戦で私なりにたどり着いた結論は、とてもシンプルなものでした。
生成AIは「魔法の杖」ではなく、対話とレビューを前提とした「優秀な相棒」である。
AIが生成した不完全なアウトプット (例えば、エラーで動かないコードや、考慮漏れのあるロジック)は、「失敗」ではありません。それは、私たちの思考を深め、より良い成果物を生み出すための「最高のたたき台」なのです。
AIを使いこなすために、今最も必要なスキルとは
この経験を通して痛感したのは、AI時代に求められるスキルセットは、根底から「変化」するというより、従来の土台の上に「進化」し「拡張」されるということです。
これからの時代、AIとの対話における「優れたプロンプト技術」が重要になるのは間違いありません。しかし、それ以上に大きな価値の差を生むのが、AIの生成物を鵜呑みにせず、その品質を厳しく見極める『レビュー能力』だと確信しました。
では、その『レビュー能力』の源泉は何か？
それは皮肉なことに、日々のコードレビューや地道なデバッグ作業などを通して、これまでエンジニアが地道に培ってきた、基本的なスキルセットそのものなのです。正しいコード構造を知っていること。パフォーマンスを意識できること。考慮漏れのあるロジックを見抜けること。これら基本的な技術力があるからこそ、AIの出力が本当に正しいのか、もっと良い方法はないのかを判断できます。
つまりAIは、私たちの基本的なスキルを不要にするのではなく、むしろその価値を、これまで以上に増幅させる「触媒（カタリスト）」のような存在なのかもしれません。
もしこの記事を読んで「自分もやってみようかな」と少しでも思ってくれたなら、こんなに嬉しいことはありません。まずは小さな業務からでOKです。あなたもAIという新しい「相棒」と一緒に、これからの働き方をデザインしてみませんか？
最後に、勉強会に参加し、率直なフィードバックをくださった社員の皆さんに心から感謝します。 「Cursorの機能説明会も！」という嬉しい声もいただきましたので、第2回の勉強会をAIと一緒に絶賛企画中です。
終わりに
冒頭でお伝えした通り、この記事の執筆もまた、生成AIとの共同作業で進められました。
私が体験した事実、アンケートの生の声、そして「この記事を通して一番伝えたいこと」という核となる想いを伝え、AIはそれらを元に構成案を作り、文章を執筆しました。
面白いことに、AIが最初に書いた文章は、客観的で少し「よそよそしい」ものでした。そこから私が「もっと人間味を出して」「ここはリアルな苦労が伝わらない」と何度もフィードバックし、対話を重ねることで、ようやくこの形にたどり着いたのです。もっとも、これだけAIと対話しても、最後は「えいっ」と自分の手で修正した箇所がいくつもあるのは、ここだけの話です（笑）。
この記事が完成するまでの道のりは、まさに勉強会の教材を作ったプロセスそのものでした。AIが出力したものを鵜呑みにせず、人間がレビューし、意図を伝え、修正を繰り返す。
AIに「書かせる」のではなく、AIと「共に書く」。 そんな新しい創作の形が、すぐそこまで来ていることを、私自身が一番強く実感しています。
最後までお付き合いいただき、ありがとうございました。