生成AI時代でも必要なIT技術とは

生成AI時代でも 必要な IT技術とは 大澤文孝 1

Who Am I? 大澤文孝 技術ライター／システムエンジニア／プログラマ／インフラエンジニア。 著書は100冊以上。 2

主な著書

主な活動 • 国交省の3D地図「PLATEAU」のチュートリアルを担当 • SchooやSEカレッジでの講師 • 同人活動（モウフカブール） – 技術書典や技書博 – 次回の技書博は10月26日 埼玉の大宮ソニックシティ （現在、サークル募集中） – OSCへの参加（このあいだOSC北海道に行ってきました）

小笠原種高の本

生成AIの参考書籍 エンジニアのためのChatGPT活用入門 インプレス エンジニアがChatGPTを活用するためのヒントを集めた 本。 ChatGPT 3.5の時代の本なので内容は古いが、生成AI、 どう使えばよいかという指針は、あまり変わらないかも。

聞くのではなくやらせる 本書の執筆を終えたとき、ChatGPTを活用できるかどうかは、正直、使い方であると 感じました。 実は当初、これほどChatGPTが使いものになるとは思っていませんでした。 その理由は、2つあります。ひとつは、リリース当初のChatGPTは、いまほど賢くなか ったこと。もうひとつは、僕の聞き方が悪かったことです。 僕は、ChatGPTに「こういうときにはどうすればいい？」「〇〇はどういう意味？」と質問 ばかりしていました。その回答は間違っていたり、的外れなものが多かったりしたので、これ では使えないなと判断したのです。 しかし本書のように、「〇〇を作ってほしい」のように指示を出すように変えたら、どうで しょう。奇外と正確なコードが出てくるではありませんか！ そう、ChatGPTは「聞くもの」ではなく、「やらせるもの」なのです。それに気づいたとき、 多くの活用のアイデアが浮かび、その日から「使えるChatGPT」となりました。

聞くのではなくやらせる • 生成AIにはハルシネーションの問題がある – 妄想で答える可能性がある – 結果が正しいかどうかの保証がない – 信用してはならない • やらせて、その結果を確認する – 自分が出力を分かっていることをやらせる

教えてもらうのはもってのほか • やらせて、その結果を確認する – 自分が出力を分かっていることをやらせる • 教えてもらうときは「情報源」を吐かせる – 自分で目視確認

生成AIの2つの用途

「作る生成AI」と「使う生成AI」 • 作る生成AI – エンドユーザー向けの生成AIアプリを作る。 – チャットボット、RAGを使ったFAQ回答など – コンテンツの要約、お問い合わせ返信案生成などの補佐 • 使う生成AI – コードを作らせる – IaCのテンプレートなどを作らせる – 設計や仕様書などのドキュメントを作らせる – テストの自動化、テストデータの生成 などなど

生成AI時代に何が求められるのか • コードの作成は生成AIに任せられる？ • 僕らは、何をしなければならず、何をしなくて済むよう になるのか • 僕らエンジニアは生成AI時代に必要なのか？

量とスピードでは勝てない 我々の負けを認めよう

数百行のコードが1分足らずでできる • 熟練したプログラマでも追いつかない

デモ • Grok (grok.com) にゲームを作らせる • 「Webで動くテトリスのゲームを作って」

生成AIなしの開発はありえない • 生成AIを使わないと、スピードで他社に負ける • 生成AIを使ってスピード感を出すこと必須 ⇒生成AIの適切な使い方を知らなければ話にならない

面倒なプログラム生成に使う • やりたいことが明確だけれど、自分で書くのが面倒な泥 臭い作業 – 生成AIを使えば、頭を使わなくていい • テキスト、HTML、XMLのパース処理とか – PLATEAUの3D地図のXMLをパースして、必要な建物だけを 抜き出すとか…… ⇒愚直にやらなければならないプログラミングほど効果がある

生成AI時代の 人間の役割

システム開発の工程 • 要件定義 • 設計 • 開発（実装） • テスト 人間の関わる範囲が大きい 人間の関わる範囲が小さい 前段（要件定義と設計）が、決まれば、何をすべき かは、決まるので自動化できる

我々人間がしなければならないこと • 要件定義 • 設計 • 開発（実装） • テスト 人間の関わる範囲が大きい 人間の関わる範囲が小さい 前段（要件定義と設計）が、決まれば、何をすべき かは、決まるので自動化できる

要件定義力・設計力を身につける 「どのように」ではなく「何をしたいか」

技術の本質 • エンジニアがこの先生きのこるためのカン ファレンス – 「知識」と「知恵」を区別して時流を乗り切る ～50年経っても現役でいられるために～ • 書籍「すべてのITエンジニアのための「一 生モノの学び方」」

要件定義・設計が苦手な人 • 何をしたいのか、何をすればゴールなのかが明確になっ ていない ⇒ITシステムの本質を知らない！？

データに着目する • ITシステムは、データを加 工しているものに過ぎない • 要件定義や設計は、物事を データでどのように表現し て、それをどう加工するかを 決める（意味付けすること）

入力、加工、出力 • プログラミングは手段 • 生成AI時代は、「こ ういう入力を、こうい う出力にするプログラ ムを作って」と言えば 作れる（③を生成AI に任せられる）

データモデリングをどう習得するか • 業務データを適切なオブジェクトやテーブルとして表現 するには？ • ⇒他のシステムを真似る – 顧客情報、商品情報など、扱うもののデータ構造は、先人た ちによって決められていることが多い

業務フローの制御などは？ • コンピュータサイエンスの基礎 – フラグを使って状態を保持する – 基本情報処理などで学べ！ • 典型的な古典的アルゴリズムをおろそかにしない • 最初は「真似」でも、どこかできちんと少しずつ基礎力 を付けよう

応用だけを追いかけるのはつらい • 業務を手っ取り早く楽に片付けるには「応用（上澄 み）」を、わかったふりして使うのが手早い – 特定のフレームワークのやり方を習得してすぐに実践で使う – どんどん新しいものが出てきて辛い

差分だけで吸収できるようにする • 応用は基礎の上に成 り立つ • 基礎を知れば、その 差分で応用もわかる • 応用の下にある基礎 技術まで視野を広げ ておくと、この先、 楽になる

生成AIへの命令の方法 正しく作らせるために

我々人間がしなければならないこと • 要件定義 • 設計 • 開発（実装） • テスト 人間の関わる範囲が大きい 人間の関わる範囲が小さい 前段（要件定義と設計）が、決まれば、何をすべき かは、決まるので自動化できる

自動でコードを作らせる • Cloude Code/Gemini CLI – 特定のディレクトリ内に「やらせたいこと」の指示書を作っ て、勝手に作らせる – かなりパワフル！ うまく動かないときに、ライブラリのほうを変更しようとす るほど力業という意味でパワフル（笑）

明確なゴールを決めること • 曖昧な指示だと成功率が低い – 何度もうまくいくまで繰り返し指示するので効率が悪い（手 離れが悪い） • その通りに実行すると完成する指示書を与える – 自分で書く or 指示書も生成AIに作らせる – Amazonの「Kiro」で変わりそう

生成AIではテストが重要視される • コードの大半を生成AIで書かせる – 人間が確認できないほどの分量になる ⇒人間が確認するのではなくテストを通ればOKとする テストによってゴールが明確になるので、生成AIのコード生成 は再試行によって確実性が高まるので、益々、自動・自律した コード生成が進む

アーキテクチャを知り正しく導くこと • テストだけ通るが碌でもないコードが登場する – ライブラリを強引に書き換えたコード – 強引に辻褄だけ合わせてるコード • 生成AIを正しく導く指示をする 自分で作れるけど、面倒だから作らない

誘導気味だと良き結果を引き出せる • 一発目では概要（汎用的、毒にも薬にもならない）しか 出てこない • 「これってこういうふうにできるよね？」（専門用語含 む。「それってPandasだと簡単にできるよね」） • 詳細な回答をし始める – おまえは知らないわけではなかったのか！

まとめ

生成AI時代を見据えた技術の習得 • 開発・テストの工程は生成AIになる • テスト重視の時代が来る • 要件定義力・設計力を磨く – 入出力データに着目していくこと – データ制御のため、古典的なアルゴリズムを知っておくと有利 なこと • 「自分でできるけど面倒だからやらない」というマインド

ご静聴ありがとうございました Follow me @sour23 モウフカブール https://mofukabur.com/