業務でAIを使いたい話

現状、「生成AIは業務の複雑なコードでは役に立たない」と感じている人も少なくないように思います。しかし、その原因はAIの能力不足だけではなく、業務のコード環境が「AIフレンドリー」でないことにあるかもしれません。業務で生成AIを使うために我々はどうすれば良いのかを考えてみました。

Transcript

1. 業務でAIを使いたい話 2025/10/29 第180回PHP勉強会資料 @hnw 1 1
2. @hnw KLabというゲーム会社でCTOしてます PHP勉強会は10年ぶりです 最初の発表は第6回 前回の発表が第94回 最近はPHP書けてないです 2 2
3. 質問1 会社で有償のAIを導入してますか？ 3 3
4. 質問2 業務のコード、AIに書かせてますか？ 4 4
5. 質問2b 9割方AIに書かせてます？ 5 5
6. AIコーディング支援の「理想」と「現実」 理想 Claude CodeやGitHub Copilotが大半のコードを自動生成 開発者はより本質的な問題解決に集中できる 現実 「うちの巨大なレガシーコードベースでは役に立たない」 「プロジェクト固有の仕様を理解してくれない」 「AIに書かせると修正コストが高い、自分で書いた方が早い」 6 6
7. プロトタイピングや使い捨てコードなら AI使えるけど、業務コードだと無理よね… って思ってませんか？ 7 7
8. なぜAIは業務のコードが苦手なのか 1. コンテキストサイズの限界 全ファイル一度に読み込むのは不可能 モデルによるが、現状だと数十〜数百ファイル程度が上限 2. 一般的ではない知識が必要 AIは内製ライブラリの知識がない 「歴史的経緯」や「複雑なビジネスロジック」の知識もない 3. 設計や仕組みがイケてないことが多い 業務では動いていることが正義 ベテランの努力と根性でギリギリ回っていたりする →つまり、業務コードはAIフレンドリーでないのが問題 8 8
9. 「AIフレンドリーな環境」とは？ 1. ユニットテスト： AIの「動作保証」と「仕様書」 2. Linter / Formatter / Type Checker： AIに「作法」を教える 3. 優れた設計原則： AIが迷わない「見通しの良さ」 9 9
10. ①ユニットテスト AIにとって、テストには2つの重要な役割があります 役割1： AIの「ガードレール」 AIは頻繁にデグレやハルシネーションを起こす 安心して使うためにテストは必須 役割2：AIの「仕様書」 テストコードが詳細仕様書代わりになる 10 10
11. ②Linter / Formatter / Type checker 問題点 プロンプトの指示でAIにコーディング規約を守らせるのは困難 明らかな型の不整合は検出したい 解決策 Linter/Formatter/Type checkerを導入 11 11
12. ③優れた設計原則 AIは（現状では）狭い範囲の整合性を取る方が得意 AI Hates 巨大な関数、神クラス 密結合、多くの副作用 AI Loves SOLID原則 単一責務の原則 (SRP) 疎結合 12 12
13. AI時代、 「良い環境」への投資はペイする これらのベストプラクティスは目新しいものではないが、 多くの現場では導入できていなかった 従来の見方 「品質」のためのコスト 寿命の短いコード、大金を稼がないコードではペイしない AI時代の見方 AIの性能を引き出し、開発速度を向上させる AIを前提にするとペイラインが変わる 13 13
14. まずは小さな成功体験から いきなり「テスト書けばAI使えます」と言っても説得力がない まずは各人が実感を持つ必要がある →やっていきましょう 14 14
15. ①OSSプロジェクトにAIで貢献しよう テストカバレッジが高いものも多い 設計も優れていることが多い →AIが能力を発揮しやすい 100%AI任せは迷惑なので、真剣に協働しましょう 15 15
16. ②AI前提の自分プロジェクトを作ろう 新規プロジェクトなら初手からAIフレンドリーにできる 既存プロジェクトをAIフレンドリーにするのは大変 私も数百行から数千行規模のAI製プロジェクトに取り組んでます @hnw/date-tibetan チベット暦のNode.jsライブラリ switchbot-actions SwitchBot製品との連携をYAMLで記述 16 16
17. まとめ AI時代こそ「良い環境」への費用対効果の説明がしやすいはず 「良い環境」でAIを使っている人はまだまだ少ない印象 みんなでAIフレンドリーなプロジェクト経験を積もう！ 17 17
18. ご清聴ありがとうございました 18 18