はじめに

『コード×AIーソフトウェア開発者のための生成AI実践入門』を拝読しました。

GPT-3あたりから、一般にも生成AIの認知が広がり、日々進歩が進んでいます。 多くの生成AIを搭載したツールが雨後の筍のごとく生まれ、そのどれもが非常に魅力的なデモで多く人々を魅了しています。 昨今では、「今後はエンジニアは不要になる」「SaaS is die」などと物騒なことも喧伝されるようにもなりました。

エンジニアの端くれとしてご飯を食べている自分としては、エンジニアという仕事がなくなってしまうと非常に困ります。 また、今年は育休を取ろうとしているのですが、エンジニアという職業が風前の灯火なのであれば、おちおち休んでいる暇ではありません。 一時的に妻の不興を買ってでもさっさと業界を逃げ出す準備が必要です。

そんな恐怖に駆られ手に取ったのが本書でした。

基本データ

全体的な概要

GitHubでアーキテクトを務める著者（GitHub Copilotにも携わってる？）が、非常に現実的な目線で昨今のプログラミング周辺を取り巻く生成AIの実情について語っています。

書籍の冒頭から力強く、以下のように宣言してくれます。

結論から言えば、エンジニアの仕事がAIに完全に奪われることはないでしょう。むしろ、AIとの共存は私たちの仕事をより創造的で価値あるものに変えていく可能性を秘めています。 服部 佑樹. コード×AIーソフトウェア開発者のための生成AI実践入門 (p.27). 株式会社技術評論社. Kindle 版.

その後は、

• 生成AIとコーディングを取り巻く現状
• プロンプトエンジニアリングの基礎や実践
• 生成AIツールのタイプごとの活用戦略
• 生成AIと協働するためのコーディングスキル
• 組織として取り組むべきこと
• 細かなTips集

など多岐にわたる内容が触れられていました。

今までやってきたことをしっかり継続すべきと思えることもあれば、生成AI時代に大きく行動や意識を変えないといけないと思わされるポイントもあります。 いずれにせよ、生成AIの特徴を踏まえて、今後個人や組織がどのようなことをしていくべきかの羅針盤になる書籍と感じました。

個人的に気になったポイント

以下で個人的に気になったポイントをまとめていきます。 これは筆者の問題意識や現状とマッチしたものを取り上げているので、書籍の中で取り扱われ方と必ずしも比例するものではないのでご了承ください。

エンジニアが読みやすいコードはAIも読みやすいコード

全編通して、言葉を変えて「エンジニアが読みやすいコードはAIも読みやすいコード」という趣旨のことが何度も触れられていました。 いかに生成AIが処理できるコンテキストが増えようとも、ある程度巨大なコードベース全てをコンテキストに含めることは現実的ではありません。 仮にコンテキストに含めることができても、生成AIの原理上、推論に扱われる情報は確率的なものになるはずです。

また、多くの生成AIツールは検索と生成を組み合わせています。 検索に引っかかるコードを書くこともまた重要です。

そのため、

• ファイル
• クラスや関数
• 各ブロック

など各レベルで単一責任原則を意識したコードを整理しておくことが重要であることがわかりました。 これは生成AI以前から言われていますが、また新しい視点で考えさせられますね。

AIと協働しやすいコード

AIがいじってもいい部分を明確にする

既存のコードを真似して新しいコードを生成することは得意ですが、既存のコードを改変する意思決定を行うことは苦手です。 服部 佑樹. コード×AIーソフトウェア開発者のための生成AI実践入門 (p.321). 株式会社技術評論社. Kindle 版.

とあるように、生成AIには自由にコードを書かせるべきで、動作しているコードを書き換えさせるべきではない。書き換えさせる場合は人間がしっかり責任を持つということが触れられていました。 そのためには、開放閉鎖原則を適用し、コードベースを拡張しやすく変更不要なようにしておくことが重要です。 こういった部分についても既存のコーディングのプラクティスがそのまま通用する部分だなと感じました。

命名大事

生成AIツールでよく使われるベクトル検索については、異言語間での比較が困難、専門用語に弱いという特徴があります。 その特徴に照らすと、bukken_idのような命名はよくなく、きっちりとした英語での命名(property_idなど)が望ましいです。 また、生成の前に検索に載るためには、同一の概念に同一の名前をつけるということが重要です。

生成AI云々以前に命名の重要性はずっと言われてきていますが、また別角度でその重要性が意識されますね。

AIにガイドラインを提供することの重要性

私なんかはよくやってしまっていたのですが、 「@selection このコードをリファクタリングしてください」といった感じの指示を出していました。 これだけではAIもどのような観点かを指定されていないため、回答の精度が安定しないようです。

本書では、Thought Works社の「リファクタリングガイド」(https://refactoring.com/catalog/)をガイドラインとしてコンテキストに含める方法が紹介されていました。

ちょっと本題からはそれますが、Thought Works社はマーティン・ファウラーが所属している会社のようです。 リファクタリングって関係者と同じリソースを共有してその価値を説得していくのが大切なので、わざわざ書籍を買わなくてもこうしてパブリックなリソースにアクセスできるのはありがたいですね。

また、同じようにガイドラインを提供すべきというのが、コードレビューについても同様でした。

このプログラムに関して、BUD の観点から問題点を特定してください。 服部 佑樹. コード×AIーソフトウェア開発者のための生成AI実践入門 (p.364). 株式会社技術評論社. Kindle 版.

SOLID原則の観点から、このプログラムにはどのような問題がありますか？ 服部 佑樹. コード×AIーソフトウェア開発者のための生成AI実践入門 (p.371). 株式会社技術評論社. Kindle 版.

曖昧な問いかけにしないで、具体的にどのような方向性に持っていきたいかをある程度指定するのは人間の役割であり、その際にいくつかパブリックなリソースが扱いやすいよねってことがよくわかりました。

今後のエンジニアに必要な素養

レビューの質と量

生成AIツールを使う以上はハルシネーションの存在は常に意識せねばなりません。 また、原理的にハルシネーションをゼロにすることはできません。 なので、エンジニア自身が嘘を嘘と見抜く素養をもつ必要があります。

また、生成AIは短時間で多くの成果物を生み出します。 今後もモデルの進化によりその傾向は強まるでしょう。 自分がレビューしやすい量に回答をコントロールしながら、AIと対話していくためにレビューの量も調整することが重要です。

AIと協働しやすい大きさ・質にタスクを整理する仕事

先にも触れましたが、AIが処理できるコンテキストは増加してきており、今後も増えていきそうです。 しかし、コンテキストに全ての情報を含んでも、期待する回答が必ずしも得られるわけではないようです。 生成AIの反応を見つつ、タスクの大きさを整えて、効率的に回答に辿り着く能力が求められます。

技術力はコモディティ化し、コミュニケーション力・問題解決能力がものをいう

生成AIの進化によって、コーディングの基礎的なプラクティスやメジャーなライブラリの使用方法などは事前学習がなされるようになっています。 著名なライブラリの典型的な使い方であれば、生成AIが一発で回答してくれることも多いです。 また、それらのツールへのアクセスも容易で多くのエンジニアが等しくそれらの能力を使えるようになりました。

そのため、特定のライブラリに精通しているという程度の技術力ではもはや差別化は難しくなりました。

そこで問われるのが、コミュニケーション力や問題解決能力です。 従来からその重要性は言われつつも、生成AIの登場により、それらの重要性がより一層高まっています。

情報アーキテクト

聞いたことあるようなないような…な言葉ですが、プロンプトエンジニアリングにおいて重要な概念として、本書で触れられていました。

『情報アーキテクチャ 第4版 ―見つけやすく理解しやすい情報設計』(www.amazon.co.jp/dp/4873117720)

技術力による差別化が難しくなり、エンジニアの仕事が情報の整理とシステムへの安全な適用となる将来が来ると思います。 その際に、情報の整理という部分で大きく貢献するのがこの辺の分野のようです。 ちょっと目を通してみようと思いました。

組織として取り組んでいくことの重要性

生成AIツールはどの会社でも簡単に導入ができます。 「使っている」だけではもはや差別化とはならず、「上手に使える」ことが求められます。

そのためには、社内のコードベースやドキュメントをAIが使用しやすいようにすることが大切です。 それは形式だけの話ではなく、組織内の壁を取り払い広い範囲で情報を共有することも求められます。

AIが使いやすいコードベースというのは、OSSのような形式のようです。 広く一般に公開するのではなく、組織内で公開するというのがインナーソースの考え方のようです。

これをどのように組織に普及・適用させていくかについても参考になりました。

AIツールの使い分け

AIツールを分類すると以下の3種類になります。

これらの分類を意識することで、新しい生成AIツールの試用をする際にも、判断の枠組みができるなと思いました。

プロンプトエンジニアリングのTips

ここからは私の印象に残ったことの一言メモです。

• システムプロンプトとユーザープロンプトは大差がない
• エンジニアの使うプロンプトの多くは使い捨て。練りに練ったものを作るより、試行錯誤を優先すべし。
• 生成AIの創造性を活かすために、制約条件は徐々にいれていくのがよい
• プロンプトの修正戦略
  • 言い換え
  • スコープ調整
  • ターゲット変更
• 約束を守るAIへの対応
  • 具体的な制約を明示
  • 強調
  • 繰り返し指示
• ロールプレイ
• 回答の対象が著名と思われるものなら、Zero-shotプロンプティングも有効

最後に

「はじめに」で生成AIへの脅威に萎縮していると書きましたが、本書を読み終えて恐怖感はだいぶ薄れました。 しかし、ある程度の行動や意識の変容が求められるであろうことも冷静に受け入れていくべきと思えるようになりました。