コード×AIーソフトウェア開発者のための生成AI実践入門
の読書メモ。

全編の要約ではなく、あくまで自分に刺さったトピックの備忘録用。

はじめに

AIを導入するだけで自動的に生産性が向上するわけではありません。真の生産性向上を実現するには、単なるテクニックを超えて、AIと上手に協働する力を身につける必要があります。AIを理解して戦略的に活用することで、生産性を飛躍的に向上させることができるのです。

短期的なツールやモデルの進化に振り回されない、真のAI活用エンジニアとしてこの先生き残るために、この観点を重視した包括的な書籍として読み始める。

本訴を通じて、読者のみなさんがAIと協働する力を身に着け、ソフトウェアエンジニアリング本来のおもしろさを再発見するきっかけとなれば幸いです。

良い一文。本来のおもしろさの部分に到達するまでの道具として活用して、そこでエンジニアとしての価値を発揮したい。

1.1 変化は「今」起こっている - さて、どうする

生成AIは表現や手段の改善に優れていますが、責任を伴う判断は、依然として人間の役割です。また、AIには全く新しい概念を生み出すことや。複雑な状況を理解して適切に解を導き出す能力には限界があることも事実です。これらの能力こそが、人間の価値を示す貴重な資質と言えるでしょう。

「複雑な状況を理解して適切に解を導き出す」こそが、「ソフトウェアエンジニアリング本来のおもしろさ」だと思うし、そこがちょうど人間の役割として残っているというのはありがたい限り。

1.3 プロンプトエンジニアリングのテクニックはあまり重要ではない

ルーティンワークの多くは既に自動化されており、エンジニアの役割はむしろその自動化を進めることにあります。この特性は、AIツールの活用において重要な意味を持ちます。各タスクの異なる要求に柔軟に対応する能力が求められます。

決まり切った作業なんてAIの力に頼らずともスクリプトでどうにかなる部分だけど、最近はそれを履き違えてAIであらゆるものを解決してしまいがちにも見える。ハンマーを持つとすべてが釘に見えるに近い問題そう。

タスクの多様性を一回性と考えると、完璧なプロンプトを作る必要はありません。むしろ、即興で使い捨てのプロンプトを生み出し、AIとの対話を通じて出力を調整する能力が重視されます。
タスクの本質を素早く見抜き、自らの知見をAIに的確に伝えることが、創造的な作業を効率的に進める鍵となります。

このためには小手先のプロンプトテクニックでなく、課題を出力を深く理解して次の入力に繋げるためのエンジニアとしての力量が求められるという話。

ビジネスやドメインの理解が今まで以上に重要になってくるんだろうなぁ。

1.4 エンジニアの仕事は消えない

AI が生成したコードを適切に理解し、運用し、改善していくには、エンジニアが必要不可欠です。

このマインドというか前提は大事にしたい。生成できる事自体に価値を感じてしまいがちなところを一歩引いた視点でちゃんと評価していきたい。

ハルシネーションに対処するには、生成AIの出力を常に批判的に評価し、複数の信頼できる情報源と照合することが不可欠です。特に、プログラミングにおいては、AIが提案したコードを理解し、その動作を確認してから採用するプロセスを徹底することが求められます。

少なくとも、自分が動作を理解していないコードをそのまま利用することは無いようにする必要がある。逆にその心持さえ持っていれば、AIの出力が多面的な学習ソースになってくれるのも嬉しい。

エンジニアの重要な役割は、生成AIの出力が要件を満たし、正確であるかを確認することです。効率的なレビューのためには、タスクを人間が確認しやすいサイズに分割することが鍵となります。

AIエージェント機能が普及した今だと、1回でAIに生成される成果物が大きくなりがちだけど、そこは適切で独立したタスクを切り出して分割統治していくことが大事なんだろうなぁ。

言語モデルが扱うトークン数の上限は、通常は「コンテキストウィンドウ」と呼ばれる一定の数のトークンに制限されます。コンテキストウィンドウとはモデルが一度に考慮できるトークン数のことであり、それを超える情報を保持することはできません。

適切なトークン数での情報提供は、AIとの効果的なコミュニケーションの鍵となります。情報が少なすぎれば必要な文脈が不足し、生成AIの出力が不適切になる可能背があります。一方、情報が多すぎればノイズも増加し、精度に影響を与えるだけでなく、処理時間も長くなってしまいます。日々の実践を通じて、最適なバランスを見つける感覚を磨いていきましょう。

AIに過剰な情報を与えることは、必ずしも良い結果をもたらしません。むしろ、的確な情報を選択して提供することが、AIの出力品質を高める鍵となります。

AIとの効果的なやり取りには、情報の「足し算」だけでなく「引き算」も同様に重要です。

このあたりの話があるから作業の分割が重要なんだろうと思う一方、このあたりのコントロールは最近のAIツールが本当に上手くやってくれるからあんまり考える必要なくなってきた説もある。

情報がないよりはあった方が良い、大は小を兼ねる時代にもなってる気がする。とは言え重複した情報で無駄にトークン消費するよりは必要十分な情報を与えるほうが良いのは間違いない。

バグだらけのコードをサブミットし、「AIが生成したからしかたない」と言い訳することは出来ません。

それはそう。

1時間あたり500行以上のペースでレビューを行うと、図に示すように欠陥の発見率が大幅に低下します。適量のコードを、ゆっくりとしたペースで、限られた時間内でレビューすることが最も効果的です。

AIのおかげでコードの生産量が10倍になった場合、10倍の量のコードレビューをしなければならないあ。もちろんレビュー自体もAIを活用することで緩和できるが、やはり最終的な意思決定は人間の役割であるため、なるべくレビュー負荷が小さくなるようにコード生成する必要ある。多分この本の後半でも出てくるけど、そのためには良質な設計、実装が必要なんだろうなぁ。

AIツールへのレビューは単なるチェック作業ではありません。AIツールの出力に対して正確な判断と意思決定を下す行為であり、エンジニアの総合的な「優秀さ」が問われるのです。

最近、コードレビューを本当に単なるチェック作業として消化している自覚があるので、ここには本当に気をつけたい。

ここでいう「優秀さ」とは、単に技術力が高いことではなく、問題解決能力、コミュニケーション力、継続的な学習意欲など、総合的な能力を指します。コードの品質、パフォーマンス、セキュリティの評価はもちろん、既存システムとの整合性やプロジェクト全体の方向性も考慮にいれる必要があります。AIツールが生成したコードを正確に理解し、プロジェクトの要件や設計方針に合致しているかを判断するには、深い技術的洞察力と幅広い視野が不可欠となるのです。

この辺読んでて、AI登場後のエンジニアの本質的な役割の解像度が高まって、少しだけだけどワクワクしてきた。

1.5 AIは優秀なエンジニアだけのものではない

AIは同じ概念や問題に対して複数の異なるアプローチや実装例を示すことができます。これにより、初心者は多角的な視点から問題を理解し、より深い洞察を得つことが可能になります。

これ普段あんまり意識できてないな。AIが生成した一種類の成果物を評価はするけど、複数パターンの生成をしてもらって視野を広げる使い方はできそうだ。

AIとの協働では、完璧な結果を初回から期待するのではなく、高速なトライ＆エラーを繰り返すことが効果的です。すばらしいプロンプトを書くことよりも、AIとの対話を通じて早く答えにたどり着くことが大切です。なぜなら、AIからのフィードバックによって、不足している情報や文脈が明確になるからです。

最近、1回の指示でエージェントに全部実装してもらおうとしがちなんだよなぁ。指示を分割して段階的に評価していくほうが良いんだろうけど悩ましい。

1.6 開発支援AIツールを使い分ける

(AIエージェントについて) これらのツールではAIが自走して動作品を完成させるため、完成品が出力されるまでエンジニアはアシストできず、レビューの機会も限定的です。エージェント型AIツールでは、精度の高い安定した出力を出すためのプロンプト設計が特に重要です。

エージェントが開発の中心になってる現代だとここのバランスムズいなぁ。不確実性の高いタスクをやらせる場合は課題を小さく分割する意識が必要そう。

1.7 AIで組織の競争力を高める

すべての企業が開発支援AIツールをなんらかの形で導入した場合、「みんなが使っている開発支援AIツールを導入すること」は他社との差別化にはなりません。今後は、AIを導入していること自体ではなく、いかに効率的にAIを活用し、同時にAIを自社の業務やニーズに適応させるかが企業の競争力を高める鍵となるでしょう。

せやなぁ。

ここで重要になるのが、インナーソースの考え方です。インナーソースとは、企業内でオープンソースのようなカルチャーを醸成し、透明度の高い協働の文化を作ることを意味します。

インナーソース、従来のOSS的な意味合いとしては社内でも頑張れてるけど、AI活用文脈だとまだまだこれからっぽい。このあたりにも貢献していきたいな。

結局のところ、AIの導入には短期的な生産性向上と長期的な価値創造のバランスが求められます。コストカットや効率化はたしかに重要ですが、そこで終わらず、新しい価値を生み出す可能性にも注目すべきです。

中長期的にAIを最大限活かすための基盤を良くしていきことと、人間に残された領域に注力するための真の技術力を高めていきたい。

2.1 システムプロンプトとユーザープロンプト

日常の業務で使うプロンプトを書く際に、100%の正確さを追求するのは効率を損なうことがあります。AIは完璧でないことを前提に、期待の8割方を満たすAI出力を目指し、残りの２割は自分で補完する方が、全体的な効率を高められます。

これは本当にそうなんだけど、いざ Vibecoding を目指そうとするとどうしても 100% になることを目指した仕組みを作ろうとしちゃうんだよなぁ。残りの２割をどう人間がフォローしやすくするかの仕組み作りのほうが大事なんだとは思うけど。

2.2 プロンプトの構成要素

プロンプトを書くときに最も重要なのは、自分自身がAIに出力してほしい答えを理解していることだと言えるでしょう。完璧な答えを知らなかったとしても、問題解決のアプローチを把握し、AIの力を借りなくても解決策を導き出せる状態が理想的です。

AIを活用する意義は、人間の理解とAIの能力を組み合わせることにあります。良いプロンプトを書くには、自分の目的を明確にし、その構造や背景、アプローチを理解していることが不可欠です。

これ！！コーディングにおける、目指しているAI活用のゴールが、「自分がやっても時間はかかるが同じ出力に到達するもの」をAIに一瞬で生成させることだと思う。今後AIがさらに進化してもこのスタンスは捨てたくない。

大規模言語モデルは、少量のデータからも新しいタスクを理解し実行可能にする能力を持っています。Few-shot プロンプティングは、大規模言語モデルのこの能力を活用し、少数の例示から新しいタスクを素早く理解させ実行させる手法です。

やっぱAI向けのドキュメントには細かい説明よりも実例を含むほうが良いのかなぁ。

著名なフレームワークや言語であるほど、モデルの学習データに含まれている可能性が高く、精度が高くなる傾向にあります。AIが既に持っている情報を引き出すことで、提供するトークンを節約しつつ、望む結果を得やすくなります。

これなぁ。既に成熟した言語、フレームワークを使うほうが圧倒的に有利な時代になって、その他のそれが芽吹かなくなっていくリスクはあるんだろうなぁと思いつつ、今後の技術選定には大きく影響しそうだなぁ。ライブラリレベルですら多分そう。

3.6 プロンプトエンジニアリングの本質

複雑なプロンプトエンジニアリングが特に重要になるのは、タスクを自動化し、人間の介入なしにAIに実行させる場合です。一方、日常的なプログラミングタスクに必要なプロンプトの多くは、使い捨てのユーザープープロンプトです。これらには複雑なテクニックや精度向上の努力は通常不要です。AIの出力に誤りがあっても、ユーザーが少し修正するだけで十分です。「日常タスクのために狭義のプロンプトエンジニアリングを学ぶ優先順位は高くない」とお伝えしたのはこうした背景からです。

わかりすぎる。プロンプトエンジニアリングを頑張りすぎないことでコスパ良くAIを活用できるけど、そのためにはやっぱりAIの出力を人間が評価する力を持っている必要がある。

一定の評価をえているシステムプロンプトから学ぶことは多いですが、それを全て真似る必要はありません。それよりも重要なのは、自分がAIを使って何を達成したいのかを明確に考えて最小限の文章で伝えることです。

ゴールを理解、言語化できる能力が重要。

4.2 対話型AIツール

AIでコードを生成するプロセスでは、「コードレビューの重要性」がよく強調されます。しかし、実際にレビューすべき対象は、AIによって生成されたコードだけではありません。自分の意図をAIに正確に伝えるためのプロンプトもまた、同様に重要なレビュー対象です。

プロンプトに含まれている前提であるとかゴールの提示に凡ミスが含まれてると、AIの出力もおかしな方向に行ってしまうけど、ついプロンプトの品質は無視してAIが頭悪いと評価してしまうことは確かにある。プロンプトエンジニアリングみたいな小手先の技に拘るよりも、与える情報が必要十分かのほうが遥かに重要。

AIの提案には「どちらも正しい」というケースがしばしばあります。そのため、AIの提案を活用する際は、人間の判断が不可欠です。開発者はプロジェクトの特性や目的を理解し、AIの提案を批判的に評価する必要があります。

受け入れ条件とかテストコードがちゃんとしてれば、まぁ正しく動くよねってコードを生成することはできるんだけど、妙に気持ち悪いというか力技だったり考慮が足りてなかったりしたコードになることがよくあるから、出力は常に厳し目に評価したい。出来ることならテストやリンターの整備で機械的に防いでいきたい。

4.3 エージェント型AI

エージェント型AIツールを効果的に活用するには、タスクの事前調査が大切です。まず、該当タスクをエージェントに依頼することが適切かどうかを慎重に判断しましょう。漠然とした期待だけで長文のプロンプトを作成するのは、貴重な時間を無駄にする可能性があります。

これは、それ自体をAIに調査させるというアプローチが効く気がする。与えられている情報だけで目的達成が可能かどうかを評価してもらって、いけそうなら着手する二段構えみたいな。

エージェントに指示を出す前にざっくりとしたプロンプトを手元で試し、AIがどの程度を理解できるのか、どの程度のコードを生成できるのかを把握していおくことも有用です。

まずは自ら調査や実装を行い、その後AIに特定の作業をイアイする方法を考えましょう。いきなり全部任せるのではなく、部分的、段階的に依頼することで、AIの生成結果を確認しやすくなります。

このプラクティスは良さそう。AIに何が出来て何が出来ないかを常に評価し続けてのが重要。

5.1 AIによる作業単位の最適化

AIが扱えるトークン数には限界があり、一度に処理できる情報量に制約があります。同時に、人間も一度に大量の情報を受け取ることは難しいものです。時に私たちは、特定のAIモデルが扱うトークン数が増えたことに一喜一憂するものですが、そのときに人間が扱える情報量がボトルネックになることを忘れがちです。

「どうせAI側が進化するから小手先のテクニックは不要」って考えも要所々々ではありつつも、人間がボトルネックになり続けるところは見極めて、そのための最適化をするのが今の最善なのかもね。

自分がレビュー可能な量を把握することが重要になります。

AIのトークン数と人間の人知能力の限界を考慮しながら、情報の入力と出力を最適化することが、AIを有効活用するうえでの重要なポイントの一つと言えるでしょう。

人間の許容量を超えると、途端にレビューをおろそかにしてAIの生成を疑いなく受け入れるように妥協してしまいそうだから、ここの境界を意識するのが重要そうだなぁ。

１つのファイルに複数の機能が詰め込まれていると、AIが情報を正確に解釈できない可能性が高まります。

たとえば、1000行のファイルがあり、AIにわたす必要がある情報がそのうちの50行だけだったとします。この場合、開発支援AIツールが1000行の中から、開発者が意図した50行を正確に抽出できるとは限りません。

残りの950行の余分なノイズデータを渡さないようにする努力が毎回必要になってしまうのです。さらに、必要な50行がファイル内に散らばっている場合、情報の抽出はより困難になります。

この辺が、AI時代においても設計が重要になり続ける大きな理由だなと思う。単一責任の原則がさらに重要になってくる。

AIの能力を最大限に引き出すには、全体の複雑な解決策をAIに求めるのではなく、いくつかの断片に分けて、それぞれの単純な解決策をAIに求めることがおすすめです。

各単位が独立して機能し、限定された文脈で理解可能であれば、AIはより意図にあった、正確で室の高い提案を生成できます。

将来的にAIの能力は拡張される可能性がありますが、人間の能力はそれほど簡単には広がりません。そのため、自分の集中力の限界を見極め、それを超えない範囲でAIにタスクを割り当てることが懸命です。

Vibecoding よろしく、一連の実装をまとめてAIにお願いしたいなと考えてはいるけど、やっぱり成果物の評価とフィードバックは小さい単位で出来るようにしたほうがいいんかなぁ。

5.2 コードのAI可読性向上

AIはある種の予測エンジンであり、書き手の癖を理解して模倣することが得意です。つまり、質の高いコードを書けばAIもそれに倣います。一方で、質の低いコードを書けばAIもそれを真似てしまう可能性があるのです。

AIが提案するコードの品質を向上させたいなら、まずは自分のコードの質を高めることが不可欠です。

既存コードに倣ってくれるから一貫性があると言えば聞こえが良いけどね。途中からAIを導入した場合は、どれだけ既存コードの品質も高められるかが重要そう。

開発支援AIツールはある種の決定論的な検索と確率論的な生成を組み合わせてコードを生み出しています。このため、AIに提供するコードやコメントは、言語モデルが処理する前に検索でヒットする必要があります。

したがって、統一された命名規則を採用し、検索にヒットしやすいコードを書くことが大切です。

同じ概念は同じ命名を使用している一貫性が重要って話ね。確かに cursor なんかに作業させると、特定キーワードで既存コードを検索してるのはよく見かける。

5.4 付加情報の提供によりAIの理解を助ける

生成AIの登場により、コメントの重要性は変化しています。今まではチームメンバーや将来の自分自身のために、多少冗長なコメントを残すこともありましたが、AIがすばやくコードを解説してくれる現在では，冗長なコメントを残す必要はなくなりました。

確かになぁ。コードを直訳したようなコメントは不要って考えは以前からあったけど、それがさらに顕著になってきそう。基本的には関数のトップレベルコメントで用途と(動的言語の場合)インタフェースだけ記載すれば良いのかな。

コメントは、AIが解説できない部分に焦点を当てることが効果的です。業務ドメイン固有の情報やビジネスロジック、クラスの状態遷移、関数の振る舞いなどには、AIが持ち得ない情報が含まれている可能性があります。

関数の実装を見るだけでは得られない(得づらい) 情報を記載すれば良いのかな。特に WHY や WHY NOT みたいな経緯の情報とか。

不必要なコメントを増やせば増やすほど、コメントと実装の一貫性を保つことが難しくなります。AIによってコメントが一瞬で生成されるからといって、不必要なコメントを増やすことは、作業効率を損なうだけでなく、AIの精度を低下させる可能性があるため、注意が必要です。

確かにAIが生成したコードには丁寧なコメントが書かれてたりするからそこも注意が必要そう。

5.5 AIが持つ知見を最大限に引き出す

AIの知識に頼りすぎることには注意が必要です。AIは時として誤った情報や古い情報を提供することがあるため、得られた情報は常に批判的に評価し、必要に応じて他の信頼できる情報源と照合することが重要です。

基本的にはAIの成果物は批判的に見る姿勢ね。

AIに知識を問うアプローチは Zero-shot プロンプティングとも呼ばれますが、その具体的な方法を理解し、うまく活用することが求められます。

前提状況を何も与えずに質問だけで生成してもらうことで、AIが持っているコンテキストを測るみたいな手法かな。積極的に使っていって、何がわかって何がわかってないかを擦り合わせていくと良さそう。

生成AIの網羅的な出力を保証する魔法のキーワードはありません。

AIにMECEなどの言葉を使っても、AIは本質的には次の文字を予測するだけで、平気で嘘をつきます。

そうなんだよなぁ。ヌケモレなくをAIに伝えるためにプロンプトで工夫することはあっても、その成功率はたかが知れてるから、コード生成の場合はリンターでカバーしたりのフィードバックの仕組みが重要なはず。

AIはアイディアを発散させることができる一方で、収斂させることは苦手です。収斂には意思決定が伴い、責任が伴います。どんなときでも最終的に責任を持つのは人間ということは、AIを使う際、常に心に留めておくべきです。

AIにコードレビューや調査をさせるときには特に大事そう。

6.1 AI に適したコードアーキテクチャ

AI と協働しやすいコードの形を考えるとき、それは同時に自分がレビューしやすいコードであることが求められます。AIはどんどんアイディアを出してくれますが、人間が時間あたりレビューできるコード行数には限りがあります。

繰り返しにはなるけど、高速で大量生成できれば良いわけじゃないってことを意識したい。

AI とリファクタリングを実施する際には、AIがコードを壊さないように注意しながら進める必要があります。

AI生成のコードをちゃんとレビューしないと痛い目見るのは、こういう観点もあるからね。

AIによるコード変更から重要なロジックを守るために、計算ロジックを意図的に独立させることをおすすめします。

計算ロジックというか、単に単一責務の原則を重視した設計にして、AIに変更してほしい箇所以外を変更されないようにする工夫が大事って話かな。

生成AIは発散が得意ですが、収斂は苦手です。つまり、既存のコードを改変する意思決定を行うことがは苦手です。

あー、これはかなり感じる。既存コードを元に予測して新規コードを書くことは出来るけど、既存コードごと改修するみたいな意図的な遠回りは出来ないよね。

OCP原則とは、ソフトウェアの設計原則の一つで、ソフトウェアの機能を拡張する際に、既存のコードを変更せずに新しいコードを追加できるようにすることを指します。

Open-Closed Principle ってそういう原則だったんだ。AI時代にはめちゃくちゃ大事にしたいやつだ。

AIが簡単に生成できるようなコードは、オープンソースソフトウェアに頼るよりもAIに任せたほうが懸命です。

この観点無かったので目からウロコ。本書では保守性とかセキュリティを理由にしてるけど、自前で書いたほうがAIがソースコードの調査もしやすいだろうし、軽微な仕組みであればOSSからコピーしてきてでもリポジトリに含めてしまったほうが良い気配がする。

6.2 AIを活用したコード品質向上

生成AIはプログラミングの世界に革新をもらたしていますが、生産性向上とコード品質確保のバランスが新たな問題となっています。

この問題、まだ顕在化してない気もする。近い将来必ず問題になってくることは目に見えているし今のうちに対策とらないとだなぁ。

AIに実装を先にしてもらい、その後でテストを書くように指示しても、生成されるテストは実装に依存してしまいます。

確かに、テストコードまで続けてAIに書かせた場合、テストが通るようにテストコード側を調整しちゃったりするから難しい。テストコードを先にAIに書かせるほうが良いのかも。

開発支援AIツールはユニットテストの生成を容易にします。しかし、「テストコードを書いて」と直接依頼するのではなく、まずは必要なテストケースの検討から始めましょう。

やはり。結局ビジネスロジックを切り出してテストを読み書きしやすくする重要性は増してきそう。

AIが生成するテストコードの品質を高めるために、テストケース設計にデシジョンテーブルを活用できます。まず、対象の関数に対してテストコードを直接生成させるのではなく、条件にもとづいてデシジョンテーブルを作成するようにAIに指示します。その後、そのデシジョンテーブルをもとにテストコードの生成を促すことで、より網羅的で有効なテストコードの作成が可能になります。

これやっていきたい。結局段階を踏んでレビューとフィードバックを繰り返すのが重要になりそうだなぁ。

6.3 コードリーディングにおけるAIの活用

AIを活用してコードを解説する際、まず自分のニーズを明確にすることが重要です。解説のレベルや詳細さを事前に決めておくことで、より効果的な結果が得られます。

漠然と説明を求めるんじゃなくニーズを言語化して依頼する。

7.1 AI時代の競争優位性を高めるための開発組織戦略

AI技術の急速な進歩により、多くの組織がAIツールの導入を進めています。しかし、真の競争優位制を獲得するには、単にAIツールを使うだけでは不十分です。組織の知識とAIを融合させ、AIを組織の一員として機能させることが大切です。

AI、雰囲気で使うだけでもだいぶ生産性向上を感じれちゃうから、それだけでめちゃくちゃ有利になった気持ちになれるけど、みんな使ってるんだから差別化は出来てないぞってことをちゃんと認識しないとなぁ。

AI を使いこなせる個人を増やすことは重要ですが、それだけでは不十分です。組織の競争優位性を高めるには、「人依存のAI活用」のレベルを超える必要があります。これらの問題を解決にするには、組織のあり方自体を見直す必要があります。優秀な個人やチームの知識をAIで活用できる状態にすることが、競争力向上の鍵になります。

使いたい人が使いたいだけ使うだと、元々あった個々人の生産性の差がさらに広がるだけで持続出来じゃない。ちゃんと組織に還元できて横展開できるように進めないと。

7.2 AI時代のソフトウェア開発手法をチームで体得する

AIの高性能さゆえに、深く考えずに「動くコード」が Pull Request として提出されることもあります。これを放置すると、エンジニアの成長機会を逃してしまいます。長期的には、チーム全体のスキル向上にも悪影響を及ぼす可能性があります。

ある程度動くコードが自動生成できるようになってくると、そこから何も学習せずにどんどん開発だけしていくみたいな状態には必ずなっていくからなぁ。学ぶべきことはしっかり学べる開発チームにしていかないと。

Slack や Teams などのコミュニケーションツールを活用し、AI活用のユースケースを日常的に共有することが効果的です。

やっぱこれよなぁ。

7.4 AI時代に適合したチーム技術スタックの最適化

開発支援AIツールが高い精度を出せる領域を見極めるとともに、チームとして戦略的に育てるべき技術スタックを選定していくことが大切です。また最新のツールを使えるように、コードのポータビリティを高め、そのうえで安全に運用できるようにすることも大切です。

AIによってリファクタであるとかツールの差し替えであるとか、これまで手数がかかっていたものをすぐにできるようになってきたんだから、それをやりやすいような、ポータビリティのある設計が重要になっていくのは感じる。

「AIは自社のコードに適した出力を出せない」という声を聞くことがありますが、オープンソースで人気の高いライブラリやフレームワークは、生成AIが事前学習している可能性が高いため、そういった問題が起こりにくい傾向があります。

人気のライブラリやフレームワークと同等のものを再実装しちゃうと、都度そのコードを文脈として与える必要があるけど、既に学習済みのOSSだったらスキップできるって話か。逆に知名度のないOSSだと不利になるから、そこの見極めが今後は重要になる？辛いねぇ。

7.5 生成AI導入効果の評価

ここで大切なのは「生産性自体をどうにかして評価する」という、非常に何回で大きなトピックにいきなり飛び込まないことです。それよりも、まずはAIツールの導入によって最低限の価値が生まれていることを確認することが優先すべき事項です。

まだそのフェーズなんだろうなぁ。AI使ってると、ついつい費用対効果大丈夫かこれってなるけど、まずは中長期的な競争で勝ち抜くために何でもいいから使ってみるフェーズなんだ。

9.1 AIを使ってより多くを成し遂げる

まず、AIが不得意とする領域での技術力を強化することが極めて重要です。これこそが、個人や組織として本質的な競争力を高めることに繋がるでしょう。

AI時代にエンジニアがこの先生き残るにはの話。これもとにかくAI活用を続けていくことで、何が人間に残された仕事なのかを見極めることからスタートなんじゃないかなぁ。

9.2 組織として技術や知識を共有し、育てる

この一連の考えをコートレベルまで掘り下げると、補陰湿的には、AIに書いてもらいたいと思えるような、使いやすく、再利用可能で、きちんとメンテナンスされているコードを地道に育てることが大切です。

やっぱりこの話に帰結するな。そして当面はそれこそが人間の重要な役割だと思える。

多くの場合、AIが読み書きすべき理想的なコードの特徴は、理想的なオープンソースコードの特徴と重なります。そう、「最新の安定版で、メンテナンスされていて、使いやすく、再利用可能であり、ドキュメントが充実している」というような特徴です。AIもこのようなコードを学習し、現在のコード生成能力を獲得しました。

AIがOSSから学習してきてるからOSSのようなコードベースと相性が良い、というのは目からウロコだ。Copilot だけは GitHub 内のプライベートリポジトリからも学習してそうだけど。

短期的な課題として、コードや情報がメンテナンスされておらず、組織で利用可能なコードが限られている場合や、コード品質が低い場合、AIによるコード生成の生産性や品質に影響を与える可能性があります。

開発者の暗黙知に頼ってる割合をどれだけ減らせるかが課題。

既存のソースコードがAIに提供される場合、それらのコードの品質がAIの生成の品質に影響を及ぼす可能性があります。

最後に、本スクラップ全体をAIに読ませてさらに要約させてみた。
まぁ納得感のあるまとめだけど、急に内容薄っぺらく見える気がしなくもない。

1. AI導入だけでは生産性は自動的に向上しない

戦略的に活用し、AIと協働する力を磨く必要がある。

2. 複雑な状況理解と責任ある意思決定は人間の領域

そこにこそエンジニアとしての価値と面白さが残っている。

3. プロンプトの完璧さよりも課題の本質理解が重要

即興で使い捨てプロンプトを作り、対話を通して出力を調整する柔軟性が求められる。

4. ドメインやビジネス理解がAI活用の質を決める

単なるツール操作力ではなく背景知識が出力の方向性を左右する。

5. AI生成コードは必ず批判的に評価し、責任を持つ

理解せずに採用しない。ハルシネーションや不正確な提案には常に警戒する。

6. 適切なタスク分割が品質とレビュー効率を高める

コンテキストウィンドウの制約やレビュー負荷を考慮して粒度を調整する。

7. AIへの情報提供は「足す」だけでなく「引く」も必要

必要十分な情報だけを渡すことで精度や処理効率が向上する。

8. コードレビューは単なるチェックではなく意思決定の場

出力が要件・設計方針・整合性を満たしているかを見極める総合力が試される。

9. エンジニアの価値は総合スキルセットにある

技術力、問題解決力、コミュニケーション力、学習意欲がAI時代でも必須。

10. AI活用後の開発プロセスも設計・品質を軸に進化させるべき

生成量増加による負荷を抑えるため、設計段階から質を意識する。