生成AI下調べ帳
生成AIについて、ソフトウェアエンジニア視点で下記のような問いを立てた。急速に進歩している分野で、全てに完全な答えを出すことはできないだろうが、おおよその見通しが立てられるよう、下調べをしておく。
- 生成AIの仕組みは?
- Transformerの仕組み
- 何がイノベーションを起こしたのか
- Self Attention
- 事前学習(Pre-training)と事後学習(Post-Training)
- Scaling Laws
- ハードウェアの進化
- GPTの仕組み
- GPT, GPT-2, GPT-3のモデル
- 事前学習(Pre-training)の仕方
- 事後学習(Post-Training)の仕方
- マルチモーダルの仕組み
- 生成AIの使い方は?
- 代表的なモデルとできること
- 生成AIが得意なタスク
- 主な使い方
- プロンプトエンジニアリング
- zero-shot, few-shot
- Chaing-of-Thought
- Tree-of-Thoughts
- Generate Knowledge Prompting
- Directional Stimulus Prompting
- 設計パターン
- 生成AI+検索
- 生成AI+Agent
- 生成AI+コード実行
- embedding
- fine-tuning
- プロンプトエンジニアリング
- 性能評価
- モデルのベンチマーク
- 下流タスクの性能評価
- 生成AIシステムの運用
- リスク管理
- 生成AIとどう関わっていけばいいのか?
- 関わり方のパターンの整理
- ソフトウェア(SaaS)業界がどう変わるか?
- 上記を受けて、個人的にはどう考えるか?
- 開発業務でどう活用するか?
- github copilot
- セットアップ
- 実装
- ドキュメント作成
- github copilot chat
- セットアップ
- コード生成
- テストコード生成
- デバッグ
- レビューリファクタリング
- コード変換
- OpenAIのAPI
- github copilot
- 顧客にどういう価値を提供できるか?
- その他、個別に深堀りしたいトピック
- 教材・学習コンテンツ
- 日本語LLM
- データセット
- フレームワーク(LangChain、LlamaIndex、Haystack等)
- Retrieval Augumented Generation(RAG)
- Program-Aided Language Models(PAL)
- 自律型AIエンジニア
- Transformerの次は?
- Transformer以前の歴史
- 改善の方向性(大規模化?軽量化?ドメイン特化?)
- Transformerの後継モデルは?
生成AIの仕組み
Transformerの仕組み
- 翻訳用に作られたモデル
- 左側がEncoderで、翻訳前の文章の特徴を数値化
- 右側がDecoderで、翻訳後の文章を生成
- Embeddingが単語のベクトル化を行い、Positional Encodingが各単語の文章における位置関係を保持
- Multi-Head Attentionが各単語同士の関連度合いの重み付け
- Layer Normalizationが重みの正規化
- Feed Forwardが意味的に関連が強い単語のペアの増幅
何がイノベーションを起こしたのか
- Self Attention
- 単語固定のベクトルではなく、まわりの文脈に応じた重み付けを含むことができる
- 並列計算できるためGPUリソースを注ぎ込めば大規模化できる
- 事前学習(Pre-training)と事後学習(Post-Training)
- 事前学習では、インターネット上の文章から機械的にマスクしたデータを利用。機械的に学習データを生成できるため、学習データの準備が比較的容易で、大量のデータを集められる。
- GPT:文章の出だしから次に何が続くかを予測させる学習
- BERT:15%のトークンを伏せ字にして、復元させる学習
- 事後学習では、質問応答など特定のタスク向けに教師あり学習などが行われる。
- 事前学習では、インターネット上の文章から機械的にマスクしたデータを利用。機械的に学習データを生成できるため、学習データの準備が比較的容易で、大量のデータを集められる。
- Scaling Laws
- パラメーター数、データセットのサイズ、トレニングに使用される計算量が増えれば、モデルの性能が上がるという法則性
- https://arxiv.org/abs/2001.08361
- ハードウェアの進化
- LLMの学習に耐えうるハードウェアの進化(GPU、TPU等)
GPTの仕組み
- モデル
- GPT
- TransformerのDecoder部分を利用
- https://cdn.openai.com/research-covers/language-unsupervised/language_understanding_paper.pdf
-
GPT-2
The model largely follows the details of the OpenAI GPT model (Radford et al., 2018) with a few modifications. Layer normalization (Ba et al., 2016) was moved to the input of each sub-block, similar to a pre-activation residual network (He et al., 2016) and an additional layer normalization was added after the final selfattention block.
- Layer Normalizationの場所が変わった
- 次の記事の解説が詳しい https://zenn.dev/sunbluesome/articles/775ffd67fb7454
-
GPT-3
- GPT2と基本的には同じモデルを用いて、パラメーター数を175 billionまで段階的に増やして性能を評価。
- GPT-3.5以降のモデルの詳細は不明
- GPT
- 事前学習(Pre-training)の仕方
- インターネット上から取得した文章・電子書籍・コードなどのデータを利用
- 文章の出だしから次に何が続くかを予測させる学習
- 事後学習(Post-Training)の仕方
- 従来のFine-Tuningは、事前学習済みモデルが有する全てのパラメーターを更新する学習を行っていたが、言語モデルの大規模化によってそれができない場合があるため以下のようなやり方が開発された。
- Instruction Tuning
- 指示文とそれに対する理想的な回答文を用いて教師あり学習
- 指示文と回答文という形式で、質問応答や分類などの下流タスクに適用させる
- 1000件程度の少量のデータでも質が高ければ、回答の品質を高められる
- Parameter Efficient Fine-Tuning
- 追加的に設定した一部のパラメーターのみを訓練・更新の対象とすることで効率的なFine-Tuningを実現
- Reinforcement Learning from Human Feedback(RLHF)
- 人間のフィードバックを用いた強化学習を通じ、人間の価値観に沿った出力になるよう調整
- ChatGPT(GPT3.5)については、Instruction TuningとRLHFの概要が紹介されている
参考:LLM 大規模言語モデル講座
GPT3.5 以降の詳細はよくわからなかったので、上記の学習の仕方については松尾研究所が無償公開しているLLM 大規模言語モデル講座の内容を参考にした。
マルチモーダル
要約すると、下記の3つのサブモデルを内蔵したモデルによって、マルチモーダルを実現
- テキストをembeddingするサブモデル
- 画像をembeddingするサブモデル
- 上記の関係を学習するサブモデル
参考:
Googel Cloud ブログ マルチモーダル検索とは何か: 「視覚を持った LLM」でビジネスが変わる
Stanford CS224N NLP with Deep Learning | 2023 | Lecture 16 - Multimodal Deep Learning, Douwe Kiela
参考資料
生成AIの使い方
主にシステムに組み込んで使っていく際の基礎知識をまとめる。
代表的なモデルとできること
-
OpenAI
- GPT-4 Turbo:OpenAIの最新モデル。GPT-4よりも安価。テキスト・コード・画像の認識や生成が可能。
- DALL-E:画像生成
- Whisper:音声認識
- Text-to-speech:テキスト読み上げ
- Google Gemini:Googleの最新のAIモデル。多種のベンチマークで好成績を残している。
- Microsoft Phi-2:Microsoftの小規模言語モデル。2.7 billion-parameterで、25倍の規模のモデルと同等の性能を実現
- Meta LLaMa:非営利目的で研究用途に限り公開されているLLM。
- ELYZA:70 billion-parameterの日本語LLM。KDDIとの資本提携なども発表している。
生成AIが得意なタスク
- 文章生成
- コード生成
- 翻訳
- 要約・要素抽出
- 質問応答
- 分類・感情分析
- チェック・校正
- 画像生成
プロンプトエンジニアリング
Prompt Engineering Guideが全般的に詳しい。以下ではそこからよく使う手法をピックアップして紹介する。
- zero-shot
- LLMが学習済み情報を元に、未知のタスクを解決すること
- 例
- 次の文章がポジティブ・ネガティブ・ニュートラルかを分類してください
- ゆとり世代だね
- 回答(GPT4 Turbo)
- この文章は「ゆとり世代だね」と単独ではポジティブ、ネガティブ、ニュートラルのどのカテゴリーに分類するかについては、文脈や話者の意図に大きく依存します。ただし、「ゆとり世代」という言葉は、時に否定的な含意を持って使われることがあります。ですが、この表現が使われた文脈や声のトーン、話者の意図が分からない限り、正確な判断は難しいです。そのため、こちらの情報だけではニュートラルと判断するのが妥当かもしれませんが、多くの場合においてややネガティブなニュアンスを持つ可能性が高いでしょう。
- few-shot
- LLMにいくつかの例を与えた上で、タスクを依頼すること
- いくつかの例示によって、回答がより意図したものになる(ことが多い)
- 例示
- Q:物品を購入する際はどういう手続をすればいいですか?
- A: 20万円以下なら購入申請、20万円以上なら稟議を出してください 。
- 質問1
- Q:本を買いたい
- 回答1(GPT4 Turbo)
- A: 本を購入する際は、購入する本の価格を確認してください。もし20万円以下であれば購入申請の手続きを進め、20万円以上であれば稟議を出す必要があります。手続きの詳細や必要な書類については、所属する組織の規定や担当部署に確認しましょう。
- 質問2
- Q:高級車を買いたい
- 回答2(GPT4 Turbo)
- A: 高級車を購入する場合、その価格はおそらく20万円を大幅に超えるでしょう。そのため、稟議を出す必要があります。稟議の手続きには、購入の意思決定を担う人々への正式な提案や承認が含まれます。これには購入する車の詳細(メーカー、モデル、価格など)、購入の理由や目的、及び購入による予想されるメリットなどが詳細に記載されている必要があります。稟議書のフォーマットや提出方法、必要な添付資料などについては、所属する組織の規定や購買部門に確認してください。また、購入にあたっては予算の確保や、場合によってはファイナンスオプション(ローンやリースなど)の検討も必要になるかもしれません。高級車購入のプロセスには複数のステップがあり、準備と承認をしっかりと行うことが重要です。
- Chain-of-Thought(CoT)
- 複雑なタスクを依頼する際に、思考過程を例示したり、ステップ・バイ・ステップで考えるように指示することで、より正しい回答が得られる方法
- zero-shotの質問
- Q: I went to the market and bought 10 apples. I gave 2 apples to the neighbor and 2 to the repairman. I then went and bought 5 more apples and ate 1. How many apples did I remain with?
- A: 11 apples (不正解)
- zero-shot-CoTの質問
- Q: I went to the market and bought 10 apples. I gave 2 apples to the neighbor and 2 to the repairman. I then went and bought 5 more apples and ate 1. How many apples did I remain with?
Let's think step by step. - A: First, you started with 10 apples. You gave away 2 apples to the neighbor and 2 to the repairman, so you had 6 apples left. Then you bought 5 more apples, so now you had 11 apples. Finally, you ate 1 apple, so you would remain with 10 apples. (正解)
- Q: I went to the market and bought 10 apples. I gave 2 apples to the neighbor and 2 to the repairman. I then went and bought 5 more apples and ate 1. How many apples did I remain with?
- Tree of Thoughts
- CoTは推論経路が一本道なのに対し、ToTでは複数の推論経路を保持し、最終的な回答を得る
- https://qiita.com/YutaroOgawa2/items/aca32f8fd7d551596cf8#09-tottree-of-thoughts
- Generate Knowledge Prompting
- 解かせたい問題に関する知識をLLMにまず生成させる
- 生成された知識を使って解かせたい問題の推論を行わせる
- Directional Stimulus Prompting
- ヒントとなるキーワードを与えることで、求めている方向にLLMを誘導する
- 例
設計パターン
これらを設計パターンと言ってよいのかは分からないが、ソフトウェアと生成AIの組み合わせによって、単体では実現できない成果が出たことが報告されている。多くはLangChainに実装されており参考になる。(参考にはなるが、LangChainも急速に進化しているため、仕様が安定しておらず、最新について行くためのメンテナンスが大変な印象。)
生成AI+検索
- Retrieval Augumented Generation(RAG)
- LLMの元から持っている知識を利用するのではなく、ユーザーの質問から検索を行い、検索結果をもとに回答を生成する
- 検索結果を元に回答を生成するので、LLMの学習データに含まれない情報についても回答ができるし、回答の際に根拠を示すことができる
- https://arxiv.org/pdf/2005.11401.pdf
生成AI+Agent
- ReAct(Reason + Act)
- Thought(思考)、Action(判断・行動)、Observation(観察)を結論が出るまで繰り返す
- Actionの部分を外部から情報を取得したり、外部処理を呼び出すAgentに処理をさせることで、外部情報を元に結論を出すことができる
- https://arxiv.org/abs/2210.03629
- Reflexion
- 過去のアウトプットをLLMで評価し記録、その記録をもとにアウトプットを行うことで精度を改善していく
- 仕組み
- https://arxiv.org/pdf/2303.11366.pdf
- Actor: 過去の評価を記録した長期記憶、短期記憶をもとにアクションを実行。ActorにはCoTやReactが用いられる。
- Evaluator: Actorによって生成されたアウトプットの報酬スコアを計測
- Self-Reflection: Evaluatorの評価と、外部からのフィードバックをもとに、今後の改善のためのフィードバックをテキストベースで生成
- 結果
- ReActと組み合わせることで、ReAct単体やCoT単体よりも高い成績を記録
- どういうときに使えるか
- 試行錯誤から学ぶ必要があるケース、従来的な強化学習ができない場合、数値的ではなく言語的なフィードバックを要する場合、学習内容の解釈可能性が重要な場合
- 連続的意思決定、QA、プログラミングなどのタスクに向いている
生成AI+コード実行
- Program-Aided Language Models(PAL)
- 複雑な問題に対応するために、プログラムを生成し、生成したプログラムを実行することで答えを得る方法
- コードのエラーを解決するためのデバッグの自動化、安全なコードの実行環境、危険なコードを除去する方法などの考慮が必要
- https://arxiv.org/abs/2211.10435
embedding
- OpenAIではテキストなどをベクトル化するembeddingという仕組みが利用できる
- https://platform.openai.com/docs/guides/embeddings
- TODO: 単純な単語のベクトル化なのか、文脈依存の重み付けがされたものなのかは後で検証する
- ベクトルデータベースと組み合わせて検索や推薦に使ったり、ベクトルを使った分類などに用いることができる
- 1M tokensで$0.13で、GPT3.5の約4分の1の価格設定のため、データ量が多い場合にも使いやすい
fine-tuning
- 対話形式のサンプルデータを追加することで、知識を追加したり、回答をカスタマイズしたりできる
- 選択できるモデルは現状ではGPT-3.5まで。GPT-4はまだexperimentalというステータスのため、GPT-3.5を独自でチューニングするよりGPT-4をそのまま使ったほうが性能が高い可能性も考慮する必要がある。
モデルのベンチマーク
各ベンチマークの特性を知っておけば、どのモデルが何に強いかを大まかに把握できる。また、カスタマイズした際の総合的な性能の評価などに用いることができる。
- ベンチマークの種類
- 読解・推論
- MMLU:専門的・学術的な知識を問う多肢選択式のタスク
- AI2 Reasoning Challence:小学校レベルの科学問題
- Big-Bench Hard:複数ステップの推論が必要なタスク
- HellaSwag:日常のタスクに関する常識的な推論
- WinoGrande:常識的な推論
- DROP:読解と算数
- JGLUE:日本語の読解のベンチマーク
- 数学
- GSM8K:小学校レベルの基礎的な算数の問題
- MATH:高度な数学の問題
- コーディング
- HumanEval:Pythonのコード生成
- 読解・推論
- GPT-4の評価に用いられたベンチマーク
- https://openai.com/research/gpt-4
- 米国司法試験やSATなど人間が行っている試験も載っている
- Geminiの評価に用いられたベンチマーク
- https://blog.google/intl/ja-jp/company-news/technology/gemini-jp/
- マルチモーダル関連のベンチマークも多く載っている
- 下記の解説が詳しい
タスクの性能評価
システムが提供するタスクの性能を維持・改善していくために、適切な評価指標を定めて、定期的に計測・調査を行う必要がある。
- 推薦
- オフライン評価
- テストデータを用いたシミュレーションで、RMSE、Precision、nDCGなどを計測
- 予測誤差指標:正解データとの誤差を測定
- MAE(Mean Absolute Error):正解との距離の絶対値の平均
- MSE(Mean Squared Error):正解との距離の2乗の平均
- RMSE(Root Mean Squared Error):MSEの平方根(ルート)をとって、元の予測値と次元をあわせたもの
- 集合の評価指標:検索・抽出した結果の中に正解が含まれる確率や精度を計測
- Recall@K(再現率):検索・抽出結果のトップK件の中に正解が含まれている確率。例えばRecall@3だと、検索結果のトップ3件の中に正解が含まれている確率を示す。
- Precision@K(適合率):検索・抽出検索結果のトップKの中に正解が何件含まれているかの比率。例えばPrecision@3において、検索結果のトップ3件の中に1件だけ正解が含まれていればPrecision@3=1/3となる。
- F1-measure:PrecisionとRecallの調和平均
- ランキング評価指標:検索・抽出結果の順序を決めるランキングの評価指標
- MRR@K(Mean Reciprocal Rank):K番以内に含まれる正解の検索順位が高いか否かを測るもの
- AP@K(Average Precision):Precisionの平均
- MAP@K(Mean Average Precision):APを各ユーザーに対して平均を取った値
- その他の評価指標:クリックの有無などで、ユーザーの満足度を間接的に測る
- オンライン評価
- A/Bテストなどで、クリック率・売上・継続率などを計測
- ユーザースタディ
- インタビューやアンケートなどで、満足度・有用性・目新しさなどを調べる
- 参考
- 推薦システム実践入門 7.2.4 評価指標のまとめ方が分かりやすいのでそれを引用
- オフライン評価
- 質問応答
- オフライン評価(RAGのシステムの場合)
- テストデータ
- SQuAD 2.0:Stanford Question Answering Dataset。10万件のQAと答えられない質問5万件。
- JSQuAD:Wikipediaベースのの質問応答データ。JGLUEに含まれ、CC BY-SA 4.0ライセンスで利用可能。
- JCommonsenseQA:常識推論能力を評価する5択選択式問題。JGLUEに含まれ、CC BY-SA 4.0ライセンスで利用可能。
- NIILC Question Answering Dataset:Wikipediaベースで、1000件。
- 運転ドメインQAデータセット:運転に関するデータ2万件。SQuAD 2.0形式。
- JAQKETクイズデータセット:クイズのデータセット13000件。
- Yahoo!知恵袋データ:Yahoo知恵袋から収集したデータ。
- 検索部分(Reader)の評価指標
- Exact Match(EM):結果文字列が正解と完全一致の場合は1、それ以外は0
- Recall@K(再現率):検索・抽出結果のトップK件の中に正解が含まれている確率。例えばRecall@3だと、検索結果のトップ3件の中に正解が含まれている確率を示す。
- Precision@K(適合率):検索・抽出検索結果のトップKの中に正解が何件含まれているかの比率。例えばPrecision@3において、検索結果のトップ3件の中に1件だけ正解が含まれていればPrecision@3=1/3となる。
- F1-measure:PrecisionとRecallの調和平均
- 回答生成部分(Generator)の評価指標
- テストデータ
- オンライン評価
- 未解決率(質問があったもののうち、人間への問い合わせが発生した件数)、回答の間違いの報告件数などを計測
- ユーザースタディ
- インタビューやアンケートなどで、満足度・有用性を調べる
- オフライン評価(RAGのシステムの場合)
- 分類
- TODO:使う時がきたら調べよう
- 翻訳
- TODO:使う時がきたら調べよう
- 要約
- TODO:使う時がきたら調べよう
生成AIシステムの運用
- MLOps
- GPTを使う場合の運用上の注意点
- 自然言語も貴重なデータで、データの質を高める仕組みが重要。人間を改善サイクルの中に入れるのが現状の最適解だが、ReflexionのようにLLMが評価・改善を行うようなサイクルも考案されている。
- ありもののモデルをAPIで呼ぶだけでも、モデルのバージョンが変わることがあるため、定期的なテストは必要。
- ファインチューニングをするなら、固有タスク向けのインストラクションデータの蓄積と精査とテストを定期的に行う必要がある。
リスク管理
- セキュリティリスク
- 情報漏洩
- AIベンダーの規約よっては、ユーザーのデータを学習に用いると書いてある場合があり、そのAIを用いることで、自社の機密情報が社外に意図せず漏洩するリスクがある。
- また、下記のプロンプトインジェクションなどで、外部に情報が漏洩するリスクもある。
- プロンプトインジェクション
- プロンプトの内容や学習データを漏洩させるようAIに指示を出すなど、開発者が意図しない動作をAIにさせることで害をもたらす攻撃。下記の記事にまとめがある。
- https://qiita.com/fuyu_quant/items/d9a44dfe3a7315f255ee
- アクセスコントロール
- 誰に何の情報を見せるかといったアクセスコントロールはAIではできないので、それを利用するアプリケーション側でコントロールする必要がある。
- 情報漏洩
- 著作権等の権利侵害リスク
- AIの学習における著作物の利用と、AIによって生成した著作物の利用のそれぞれで考慮が必要。
- 日本では現状、AIが文章や画像を学習する際に、営利・非営利問わず著作物を使用することができる
- 米国では、著作物を許可なくAIの学習に利用されたとして訴訟が発生
- 人がAIを使って生成した著作物の利用については、一般の著作物と同様
- 現状OKでも、今後各国で法規制が強化される可能性があり、動向のチェックが必要
- 倫理的に不適切な発言のリスク
- OpenAIはModeration APIを設けて、ヘイト・ハラスメント・性的・暴力的などリスクのある表現を検知できるようにしている
- ハルシネーションやAIの過信によるリスク
- AIは事実ではない誤った情報を、事実かのように生成することがあり、現時点では事実確認は必ず行う必要がある。
- また、フェイク情報なども生成しやすくなっているため、ネットの情報などで事実確認を行う際は、これまで以上に注意深く裏取りをしなければならない。
関わり方
ソフトウェアエンジニアとして、生成AIとどう関わっていけばいいのか?
関わり方のパターンの整理
- AIの提供者
- 独自モデルを開発する
- 大規模化路線
- 軽量化・計算量削減路線
- ドメイン特化路線
- 汎用モデルを独自データでチューニングして提供する
- LLM周辺の課題解決に貢献する
- データ作成・評価
- セキュリティ
- AI倫理とコンプライアンス
- 教育とトレーニング
- 独自モデルを開発する
- AIの利用者
- 自社サービスに組み込んでお客さんに価値を提供する
- コンサルや受託でAI関連の業務を請け負う
- 自社の業務を改善する
ソフトウェア(SaaS)業界がどう変わるか?
LLMとプログラミングの終わり
- Large Language Models and The End of Programming - CS50 Tech Talk with Dr. Matt Welsh
- Harvard UniversityでのTech Talk
- 現在は生成AIでコード生成をしているが、コードは人間が読むためのもの
- 将来的にはコンピューター向けの命令を直接AIが生成することで、プログラミングは不要になっていくという内容の話
GartnerのCIO向けのイベント
-
7 Disruptions You Might Not See Coming: 2023-2028 l Gartner IT Symposium/Xpo
-
- Geomagnetic Storm impact.
-
- AI Driven Legacy Modernization ☆
-
- AI Regulation ☆
-
- Silver workers
-
- Startup on sale "Laggards Leapfrog Leaders" ☆
-
- The pace of Engineering inovation is going through the loof. ex. SpaceX
-
- Space race is starting again.
-
- ソフトウェア(SaaS)業界に大きな影響を与えそうなのが、2のAIによるレガシーシステムの刷新と、5のスタートアップが大企業に買収されていく流れ
- 3のAIの法規制に関する動向も継続的にウォッチが必要
AIによるスタートアップの変化 フルスタック・スタートアップへ
-
SaaSビジネスがいま、AIで大きく変わろうとしている
- これまでのSaaSは実務家を支援するソフトウェア(例:法律文書の作成を支援するソフトウェア)を売っていた
- LLMの登場により、実務家の作業そのもの(例:作成した法律文書)を提供するようになってきた
- このように、バリューチェーンの最初から最後までを一貫して自社で扱い、プロダクトやサービスを生み出す企業を「フルスタック・スタートアップ」という
上記を受けて、個人的にはどう考えるか
- 以下はあくまで個人的な予想と考え。
- 生成AIがビジネスに与えるインパクトは大きく、いま業界がいろいろ蠢いている最中なので、どの関わり方のパターンであってもチャンスがある。ただ自分はAIの最先端の基礎研究の能力がある訳でもなく、巨大な資本やデータにアクセスできる立場にないため、どちらかというとAIの利用者視点での関わり方がメイン。
- 人間のプログラマを不要にするレベルの技術は早晩実用化されるだろうが、そうなってくるとこれまでのプログラミングやソフトウェアエンジニアリングに関する知識や仕事のやり方は一新しなければならない。他方で、コンピューターサイエンス、プロダクトマネジメント、ビジネスモデリング、セキュリティなどはあまり影響を受けないかもしれない。いずれにしろ、レガシーシステムの置き換えまで含めると10年単位の時間がかかるだろうから、その間に準備しておかなければならない。
- 現状普及しているノーコードツールやRPAは、生成AIとのハイブリッド型か、生成AIネイティブなツールに置き換わっていくだろう。
- 生成AIですぐ作れるレベルのSaaSアプリは、次世代のノーコードツールで代替されるなどして淘汰されていくことになる。
開発業務での生成AIの活用
使い分け
- github copilotは、コーディングやドキュメント作成など、IDEやCLIで入力をしながら自動補完をしてもらう際に用いるとよい
- github copilot chatは、テストコードを生成したり、レビューを依頼するなど、コードを書きながらでは指示がしにくいような複雑なことをAIに頼む時に用いるとよい
- OpenAIのAPIは繰り返しの作業や、複数のプロンプトをつなげて利用する際に、プログラムから呼び出す際に利用する
github copilotの利用方法
実装
- 基本的な使い方
- https://docs.github.com/ja/copilot/using-github-copilot/getting-started-with-github-copilot#seeing-your-first-suggestion
- VSCodeへのCopilotのインストール
- コード補完を受け入れる
Tab
- 代替候補(別の候補)を表示する
Alt+]
orOption+]
- 候補を部分的に受け入れる
Control+→
orCommand+→
- コメントからコード生成(コメントを書いたらその後に候補が出る)
- コードからコメントを生成(コードを書いて、その上にコメントを書き始めたら候補が出る)
- 分かりやすい解説
ドキュメント作成
- ドキュメント作成時の文章の補完
- Mermaidの記法で、ER図やUMLなどを作成
- OpenAPIの作成
github copilot chatの利用方法
セットアップ
コード生成
- テストコード生成
- コードの改善点の提案
- コードのデバッグ(エラーメッセージなどから修正を提案)
- OpenAPIからコードの大枠を作成
レビュー・リファクタリング
性能比較
TODO: レビューでの利用については、下記のケースでどれが一番性能がよいかを確認する必要がある
- 単に「レビューをしてください」と依頼する場合
- まとめて、「下記の観点でレビューしてください」と依頼する場合
- 一つ一つの観点ごとにレビューを依頼する場合
レビューやリファクタリングでの利用シーン
- 名前の改善
- 関数名や変数名が読みやすくわかりやすいものか、Typoがないかをチェックしてください
- コメントの付与
- コメントは適切に付与されていますか
- ドキュメントの確認
- 関数ドキュメントが適切に付与されていますか
- 重複チェック
- 重複しているコードがあれば、重複をなくすための改善案を提示してください
- 関数・クラスの分離
- クラスの凝集度やサイズ、クラス間の結合度は適切ですか
- 関数のサイズは適切ですか
- 1つの関数に複数の役割がありませんか
- セキュリティの脆弱性チェック
- コードにセキュリティ脆弱性がないかをチェックしてください
- 性能改善提案
- 効率の良いコードが書かれていますか?改善点があれば提案してください
- エラー処理・例外処理のチェック
- エラー処理・例外処理が適切に行われているかをチェックしてください
- ユーザビリティの観点から、出力しているエラーメッセージは適切ですか
- 運用性の観点からログメッセージは適切ですか
- テストの網羅性のチェック
- テストケースが網羅されていますか
コード変換
- 別言語への移行
- 他のDBMS用のSQLに変換
リバース・エンジニアリング
- コードの説明
- テーブルからER図を作成
- コードからシーケンス図を作成
- コードからOpenAPIの大枠を作成
(Azure) OpenAI GPTの活用
現状では、github copilotをプログラムから利用するAPIは公開されていないようなので、プログラムで繰り返し処理をしたい場合などは、OpenAIのAPIを利用するのがよいか。(language server経由で呼び出す方法を見つけた人がいるが、公式に保証されたやり方ではなさそう。)
- データ分析・分類
- レビューツール
- CIへの組込み
顧客にどういう価値を提供していくか
- SaaSビジネスがいま、AIで大きく変わろうとしている