業務でAIを使いたい話 2025/10/29 第180回PHP勉強会資料 @hnw 1 1 

@hnw KLabというゲーム会社でCTOしてます PHP勉強会は10年ぶりです 最初の発表は第6回 前回の発表が第94回 最近はPHP書けてないです 2 2 

質問1 会社で有償のAIを導入してますか？ 3 3 

質問2 業務のコード、AIに書かせてますか？ 4 4 

質問2b 9割方AIに書かせてます？ 5 5 

AIコーディング支援の「理想」と「現実」 理想 Claude CodeやGitHub Copilotが大半のコードを自動生成 開発者はより本質的な問題解決に集中できる 現実 「うちの巨大なレガシーコードベースでは役に立たない」 「プロジェクト固有の仕様を理解してくれない」 「AIに書かせると修正コストが高い、自分で書いた方が早い」 6 6 

プロトタイピングや使い捨てコードなら AI使えるけど、業務コードだと無理よね… って思ってませんか？ 7 7 

なぜAIは業務のコードが苦手なのか 1. コンテキストサイズの限界 全ファイル一度に読み込むのは不可能 モデルによるが、現状だと数十〜数百ファイル程度が上限 2. 一般的ではない知識が必要 AIは内製ライブラリの知識がない 「歴史的経緯」や「複雑なビジネスロジック」の知識もない 3. 設計や仕組みがイケてないことが多い 業務では動いていることが正義 ベテランの努力と根性でギリギリ回っていたりする →つまり、業務コードはAIフレンドリーでないのが問題 8 8 

「AIフレンドリーな環境」とは？ 1. ユニットテスト： AIの「動作保証」と「仕様書」 2. Linter / Formatter / Type Checker： AIに「作法」を教える 3. 優れた設計原則： AIが迷わない「見通しの良さ」 9 9 

①ユニットテスト AIにとって、テストには2つの重要な役割があります 役割1： AIの「ガードレール」 AIは頻繁にデグレやハルシネーションを起こす 安心して使うためにテストは必須 役割2：AIの「仕様書」 テストコードが詳細仕様書代わりになる 10 10 

②Linter / Formatter / Type checker 問題点 プロンプトの指示でAIにコーディング規約を守らせるのは困難 明らかな型の不整合は検出したい 解決策 Linter/Formatter/Type checkerを導入 11 11 

③優れた設計原則 AIは（現状では）狭い範囲の整合性を取る方が得意 AI Hates 巨大な関数、神クラス 密結合、多くの副作用 AI Loves SOLID原則 単一責務の原則 (SRP) 疎結合 12 12 

AI時代、 「良い環境」への投資はペイする これらのベストプラクティスは目新しいものではないが、 多くの現場では導入できていなかった 従来の見方 「品質」のためのコスト 寿命の短いコード、大金を稼がないコードではペイしない AI時代の見方 AIの性能を引き出し、開発速度を向上させる AIを前提にするとペイラインが変わる 13 13 

まずは小さな成功体験から いきなり「テスト書けばAI使えます」と言っても説得力がない まずは各人が実感を持つ必要がある →やっていきましょう 14 14 

①OSSプロジェクトにAIで貢献しよう テストカバレッジが高いものも多い 設計も優れていることが多い →AIが能力を発揮しやすい 100%AI任せは迷惑なので、真剣に協働しましょう 15 15 

②AI前提の自分プロジェクトを作ろう 新規プロジェクトなら初手からAIフレンドリーにできる 既存プロジェクトをAIフレンドリーにするのは大変 私も数百行から数千行規模のAI製プロジェクトに取り組んでます @hnw/date-tibetan チベット暦のNode.jsライブラリ switchbot-actions SwitchBot製品との連携をYAMLで記述 16 16 

まとめ AI時代こそ「良い環境」への費用対効果の説明がしやすいはず 「良い環境」でAIを使っている人はまだまだ少ない印象 みんなでAIフレンドリーなプロジェクト経験を積もう！ 17 17 

ご清聴ありがとうございました 18 18