はじめに Kubernetesとは？ コンテナとは？ Kubernetesでできること コンテナの管理 デプロイの自動化 スケーリングの自動化 Kubernetesのアーキテクチャ概要 Pod Podを管理するワークロードリソース Kubernetesの構成 コントロールプレーン ノードコンポーネント 実際に触って理解してみる 環境準備 minikubeでクラスタを起動する Podを起動してみる（nginx） namespaceの違いを確認する namespaceを作成してPodを起動してみる Podの動作を確認する（curl） 片付け まとめ はじめに はじめまして！ 2025年度新入社員の…

生成AI初心者エンジニアが3ヵ月でAI駆動開発を習得するまで こんにちは。LIFULL HOME'S の CRMで開発を担当しているソンです。 2025年4月に復職してから、業務では生成AIをほぼ使ったことがない状態でしたが、社内ではAI活用や導入が活発に進み始めていました。エンジニアチーム内ではAI活用の開発手法を学ぶ社内研修が行われており、自分も参加して実際にAIを活用した開発を経験できていました。そしてAI活用開発プロジェクトの担当になったとき、本格的に生成AIを利用した開発を始めようとしていました。 この記事では、生成AI初心者だった私が試行錯誤しながら、本格的にAI駆動開発に取り組んだ直近3ヵ月（2025年12月〜2026年2月）の過程と、そこから得た学びを共有します。最初の1ヵ月は失敗続きでしたが、社内のサポート体制やナレッジ共有を活かすことで、月あたりのGitHub Contributionが約3.5倍に増加しました。担当プロジェクトではCTR・CTORの改善成果も得られました。同じように「AIを使ってみたいけど、どう始めればよいかわからない」という方の参考になれば幸いです。 生成AI初心者エンジニアが3ヵ月でAI駆動開発を習得するまで プロジェクト概要 開発したもの 最初の壁：「適当な」プロンプトの代償 期待と現実のギャップ 具体的な失敗例 失敗1：複雑すぎるコード 失敗2：AIも間違える——参照先の確認不足 転機：チームとサポートの力 職種を超えたAI活用の文化 全社共有の設定とツールの活用 keelaiチームの手厚いサポート 成果：数字で見る変化 アウトプット量の変化 コード品質の向上 学んだこと：3ヵ月の試行錯誤から 1. AIをどう使うかを考える 2. 設定と使い方を学ぶことが成功への近道 3. 生成AIは日々成長している。恐れず耳を傾けよう 4. チームとサポートの重要性 今後の課題と展望 AIへの依存度が高まる怖さ さらなる活用の可能性 終わりに プロジェクト概要 開発したもの シナリオメールという、問い合わせ（反響）を行ったユーザーに対して配信されるレコメンド物件メールがあります。このメールで推薦される物件に対して「なぜその物件がお勧めなのか」を生成AIで自動説明し、ユーザーの物件理解促進とCVR（コンバージョン率）向上を図るプロジェクトでした。 レコメンド物件は毎回ユーザーごとに変わるため、手動やロジックだけでは自然な推薦文を作ることが難しいという課題がありました。そこで、生成AIを活用して物件の特徴を自然言語で説明する方法を採用しました。 結果として、既存パターンと比較してCTR（クリック率）が6.03%→6.31%、CTOR（クリック・トゥ・オープン率）が8.20%→10.7%に改善しました。 最初の壁：「適当な」プロンプトの代償 期待と現実のギャップ 最初のプロンプトで作られたコードを見た感覚ではうまくやれば2日もかからず終わりそうだと思っていました。 開発を行ったリポジトリのアーキテクチャにも沿っているし、APIで必要な基本的な構造やチェック、テストコードもできていました。 しかし、詳細をチェックしていくと問題だらけでした。 具体的な失敗例 失敗1：複雑すぎるコード 生成されたコードは、一見すると「ちゃんと動きそう」に見えました。しかし、実際には以下のような問題がありました。 エラーハンドリングが過剰で、本来キャッチすべきでないエラーまで握りつぶしていた 不要な抽象化レイヤが追加され、コードが読みにくくなっていた パフォーマンスを考慮していない実装（毎回ファイルを開閉するなど） 結局、生成されたコードの一部では手作業で修正したり、AIに再度修正を依頼したりの繰り返しでした。「最初から自分で書いた方が早かったのでは？」と感じたときもありました。 失敗2：AIも間違える——参照先の確認不足 OpenAIのPrompt Caching機能を使った設計と実装を、AIコーディングアシスタント（Claude）に依頼したときのことです。OpenAIの公式ドキュメントのURLも参考資料として渡していました。 しかし、実際にはURLの読み込みに失敗しており、AIはOpenAIではなく自分自身（Claude）のPrompt Cachingの仕様に基づいたコードを生成していました。両者ではPrompt Cachingのしくみが異なるため、そのまま使えば動かないコードになっていたのです。PRから作成されるEphemeral Environmentでテストしたところ、改修内容が反映されていないことに気付き、もう一度ドキュメントを確認して原因が判明しました。 AIが「もっともらしく」回答しているときほど要注意です。前提となる情報源を正しく取得できているか、出力結果が意図した仕様に基づいているかを常に確認する必要があります。 それでも使い続けた理由は、これはAIの実力の問題というよりは使い方の問題であることがわかったからです。 転機：チームとサポートの力 職種を超えたAI活用の文化 社内のSlackでもさまざまなナレッジが共有されていますが、月1回の定例で行っているエンジニア組織の月次定例会でも生成AIを活用したナレッジ共有とワークも行っています。 そこで学んだ開発手法や共有されたプロンプトが大きな力になりました。 また、エンジニアチームだけでなく、CRMチームでは非エンジニアメンバーの間でも生成AIの導入と活用が活発に行われています。普段の会話の中でも自然にナレッジ共有ができており、職種を超えたAI活用の文化が根付いています。 全社共有の設定とツールの活用 社内では、MCP（Model Context Protocol）を使ったPrompt-serverが提供されており、開発関連のプロンプトが共有されていました。MCPとは、AIツールが社内のコードベースや開発ルールを参照できるようにするしくみです。 さらに、全社で生成AIを活用するための設定が共有されています。これにより、個人でゼロから環境を整える必要がなく、すぐに生成AIを活用できる基盤が整っていました。 周りから学んだナレッジを一つ一つ適用していくことで、少ない手順で目標の成果物へ近付けるようになりました。そしてナレッジを学んで適用していくのがどんどん楽しくなりました。 keelaiチームの手厚いサポート このプロジェクトで最も助けられたのが、社内のAI活用推進チームであるkeelaiチームのサポートでした。 開発中のPRをそっと見に来てくれて、性能改善に役立つコメントやリンクを教えてくれる Slackで企画メンバーと相談していると、まだメンションも投げていないのに現れて、理由や解決方法を教えてくれる まるでAIのような対応速度と的確さで、初めて生成AIを使う私にとって、これ以上ない心強いサポートでした。 成果：数字で見る変化 アウトプット量の変化 GitHub Contributionを見ると、変化は明らかでした。 2025年（4月〜12月） : 229 contributions 2026年（1月〜2月） : 186 contributions 2025年は9ヵ月間で229 contributions、月平均約25件。2026年は約2ヵ月で186 contributions、月平均約90件。contributionの数がそのまま開発速度を表すわけではありませんが、アウトプット量の変化を示す一つの指標として、月あたりの生産量で比較すると約3.5倍のペースになっています。 コード品質の向上 アウトプットの量の変化だけでなく、コードの質も向上しました。 コメントの充実 : AIでコードを生成することで、抜けがちなコメントが詳細に作成されるようになった 設計書の詳細化 : 仕様駆動開発（要件定義→設計→実装の順にAIと対話しながら段階的に進める手法）を取り入れ、要件と設計を明確にしてから開発するようになった。手作業では時間がかかるフロー図やシステム図の作成が簡単になり、記載漏れが減った テストケースの網羅性 : エッジケースを含めた包括的なテストケースを生成できるようになった 学んだこと：3ヵ月の試行錯誤から 1. AIをどう使うかを考える 最初の失敗から学んだ最も重要なことは、AIは 優秀 だがあくまでも アシスタント であることです。 AIは、与えられた情報の範囲内で最善の出力をしようとします。しかし、情報が不足していたり、参照先が間違っていれば、不完全な出力しか得られません。 大切なのは「AIをどう使えば効率的か」を常に考えることです。 2. 設定と使い方を学ぶことが成功への近道 プロンプトの書き方も大切ですが、それ以上に重要なのは、AIを使うための環境設定と基本的な使い方を理解することです。 社内で共有されているAIツールの共通設定を活用すれば、個人で試行錯誤する時間を大幅に短縮できます。MCPやPrompt-serverといったツールの使い方を学んだことで、AIの能力を最大限引き出せるようになりました。 良い設定と使い方の条件は、以下のようなものです。 再現性 : 誰が使っても同じ結果が得られること 共有可能 : チーム全体で活用できること 拡張可能 : 新しいユースケースに対応できること そして、設定や使い方自体もチームでレビューし、改善していくべきものです。 3. 生成AIは日々成長している。恐れず耳を傾けよう 生成AIの技術は日々進化しています。「以前試してダメだったから」と諦めるのではなく、常に最新の情報にアンテナを張り、新しい可能性に耳を傾けることが大切です。 私の場合、最初の1ヵ月は失敗続きでしたが、周りの情報やサポートに耳を傾けて、積極的に試してみることで、3ヵ月後には開発速度が約3.5倍になりました。 AIの進化速度は想像以上に速く、数ヵ月前には不可能だったことが今では当たり前にできるようになっています。恐れずに、まずは試してみることが重要です。 4. チームとサポートの重要性 一人でAIと格闘していたら、おそらく挫折していたと思います。 チームでプロンプトを共有し、レビューし合う文化 Prompt-serverのような、知見を蓄積・共有するしくみ keelaiチームのような、専門家のサポート これらがあったからこそ、短期間でAI駆動開発を習得できました。 会社でも積極的にAI活用を支援しているので、最近では非エンジニアの間でもAIを使うときのコツがよく共有されています。この流れは、今後さらに加速していくでしょう。 今後の課題と展望 AIへの依存度が高まる怖さ 最近、少し怖いと感じることがあります。 直接コードを書くことや、繰り返し行われる作業を見ると、ついついプロンプトを作ってAIに任せたくなるのです。 これは効率的である一方、基礎的なコーディング力が落ちるリスクもあります。AIに頼りすぎず、自分で考える時間も大切にしたいと思っています。 さらなる活用の可能性 今回のプロジェクトを通じて、AIの可能性を実感しました。 今後は以下のような活用も試していきたいと考えています。 設計段階でのAI活用の深化 : 仕様駆動開発（要件定義→設計→実装を段階的にAIと進める手法）を始めているが、要件定義の精度をさらに上げたい チーム横断でのプロンプト標準化 : 個人の知見をチーム全体の資産にするしくみづくり AIの出力品質の定量評価 : 生成コードの品質を客観的に測定する基準の確立 終わりに 生成AI初心者だった私が、3ヵ月のAI駆動開発で学んだことです。 「AIをどう使うか」を常に考える 設定と使い方を学ぶことが成功への近道 生成AIは日々成長している。恐れず耳を傾ける チームとサポートの力を活かす もしあなたが「AIを使ってみたいけど、どう始めればよいかわからない」と思っているなら、まずは小さく始めてみてください。 最初はうまくいかないかもしれません。私も最初は失敗続きでした。しかし、諦めずに試行錯誤を続ければ、必ず成果は出ます。 そして、周りの情報やサポートに耳を傾けてください。一人で悩むより、チームで共有し、専門家に相談する方が、はるかに早く成長できます。 AIを使った開発は、もはや「特別なスキル」ではなく、「当たり前のスキル」になりつつあります。この波に乗り遅れないよう、今日から一歩を踏み出してみませんか？ 最後に、ともに開発フロー改善に取り組んでくださる仲間を募集しています。 hrmos.co hrmos.co

作業の合間に窓の外を眺めることはありますか？ 筆者の席は会社のビルの西側で、午後になると大きな窓から強烈な西日が射し込んできます。 それがあまりに強烈なので、いつもブラインドが閉まっていて外があまり見えません。 そのせいでオフィス内の移動中などに窓から見えた空が真っ暗で驚くということがよくあります。それで困るというわけではありませんが、少し味気ない感じがします。 空の色で時間の移ろいを感じたい。 隙間から覗くこともある というわけで、机に置いて空の色で時間帯を知らせてくれるデバイスを作ることにしました。それだけでもつまらないので、机の上にあったら嬉しいポモドーロタイマーの機能も付けてみ