【SW勉強会コラム】「AIがコードを書く時代、人間のボトルネックは“理解”になる」ー暗号実装開発における生成AI活用のリアルと教訓

毎週水曜日に開催している、技術共有・スキル交流を目的とした社内勉強会。AI、インフラ、クラウド、開発、QAなど、各ユニットが持つ知見を共有するこの場も、今回で第12回目を迎えました。 今回の登壇者は、SACユニットのH.A.さん。テーマは「暗号実装の開発で生成AIをどう使ったか」です。 生成AI（LLM）の恩恵を語るだけでなく、現場で直面した「失敗」や、開発プロセスにおける「新たな課題」まで赤裸々に語られた本セッション。求職者の皆様にも当社のリアルな開発カルチャーが伝わるよう、そのエッセンスをお届けします。

生成AIの台頭により、開発のあり方は劇的に変化しています。しかし、H.A.さんは冒頭で「LLMの限界は仕組みから説明できる」と指摘しました。 LLMは本質的に「次に来る言葉（トークン）を確率で選び続けている」だけであり、モデルの内部には「知らないことを保証する仕組み」がありません。そのため、もっともらしい嘘（ハルシネーション）をゼロにすることは原理的に不可能であり、テストコードを通したり、人間がレビューや一次情報を確認したりといった「外側からの検証」が不可欠であると語られました。

セッションでは、実際の業務での活用事例が紹介されました。 1つ目の事例は、仕様が公開されている暗号アルゴリズムを、既存のOSSにプラグインとして追加実装するというタスクです。H.A.さんは、AIに対する指示を細かく共通認識として「仕様書」の形に落とし込み、それを土台に実装を進めさせました。結果として、本来なら2週間程度かかりそうな実装とドキュメント作成の期間を、大幅に短縮することに成功しました。

しかし、ここで大きな失敗も経験したと言います。長年メンテナンスされてきた既存のコア実装を、AIに新しく書き直させたところ、実行時間が従来の2倍以上遅くなってしまったのです。長年使われてきたコードには「書かれていない見えない制約条件」が含まれており、既存実装をむやみに書き換えることには慎重になるべきだという教訓を得たそうです。

2つ目の事例は、「論文の記述のみをもとに、研究用の暗号実装を作る」という難易度の高いものでした。 仕様が明確だった1つ目の事例とは異なり、論文という抽象度の高い情報から仕様書を生成して実装に進もうとしたところ、AIが思考にトークンを消費しすぎて上限を使い切ってしまう問題が発生しました。さらに、既存の制約条件を満たせない実装が出力されてしまったと言います。

そこでH.A.さんは、AIに任せる前に人間側で基本型やAPIといった具体的な設計を行い、「抽象度を下げてからAIに任せる」というアプローチに切り替えました。仕様がどこまで外部にあるか（明確化されているか）によって、AIに任せられる範囲や抽象度は大きく変わるのです。

この開発を通じてH.A.さんが行き着いた最も深い洞察は、「実装を早くすると、次は『人間の理解』が律速（ボトルネック）になる」という事実でした。 AIに指示を出せば、コードは瞬時に生成されます。しかし、最終的にそのコードが正しく動いているか判断し、他者に説明するのは人間の役割です。生成スピードに対して、人間の理解が追いつかなくなっていく問題に直面したのです。

そこでH.A.さんは、理解を効率化するためにAIの使い道を変えました。「AIに自分に対する質問を作ってもらって自分の理解の穴を見つける」「論文とコードの対応表を作らせる」「自分が他者向けに書いた説明文をAIに添削させる」といった方法を取り入れたのです。AIを「コードを書く存在」としてだけでなく、「人間の理解を深める壁打ち相手」として活用する素晴らしいアプローチでした。

「AIを使って速く作れました」という単純な成功譚ではなく、トークン枯渇やパフォーマンス劣化といった生々しい失敗談、そして「人間の理解がボトルネックになる」という本質的な課題提起まで、非常に濃密で実践的なセッションでした。質疑応答でも、コードを読む際の具体的な工夫について活発な意見交換が行われました。 新しい技術をただ盲信するのではなく、仕組みを理解し、失敗から学び、実務のプロセスをアップデートしていく。そんな当社の開発カルチャーを象徴する時間だったと感じます。

当社では現在、最新技術を探求しながら、共にプロダクトと組織を成長させていく仲間を募集しています。このような技術交流や課題解決のプロセスにワクワクした方は、ぜひ採用ページもご覧ください！