Kubernetes 1.35では、kube-proxyの動作モードのうち、IPVSモードが非推奨（deprecated）になりました。 https://kubernetes.io/blog/2025/12/17/kubernetes-v1-35-release/#deprecation-of-ipvs-mode-in-kube-proxy 本稿では、このIPVSモードの非推奨化を受け、最近のkube-proxyの動作モードについて調査した内容をまとめます。 kube-proxyとは kube-proxyは、Kubernetesのコアとなるコンポーネントの一つです。 Kubernet

はじめに 直近のAIエージェントシステムの構築案件にて、主に基盤の設計から構築に携わっていました。 その中でもMicrosoft Learnなどを読むだけでは理解しづらかった点や、実際の設計・構築を通して悩んだこと、学んだことをまとめます。 本記事では2つのテーマを扱います。 Azure Container Apps Environmentという概念と分け方 Azure閉域化の基本 - VNet統合とPrivate Endpoint 基本的な内容も含まれますが、あらかじめご了承ください。 想定読者 Azureで業務システムを構築している方 Microsoft Learnだけ

【目次】 AIが入っていない場所を探したら、上流工程が残った なぜ「概要設計書」を選んだのか 「書き直させる」前提で、最初からAIに書かせた つまずいたのは、スライドのデザインとUIのデザインの混在 ツール選定に、20分以上かけない 体感で2〜4倍。ただし数値化はこれから 生まれたバッファは、顧客の声を拾う時間へ まとめ こんにちは、ラクス技術広報です。 開発本部では、各部署でのAI活用の取り組みを技術広報がインタビューし、記事としてお届けしています。今回お話を伺ったのは、経費・請求・販売管理などのクラウドサービスを展開するラクスで、販売管理クラウドサービス「楽楽販売」の開発を担う 楽楽販売開発1課の前田啓佑さん です。 前田さんが取り組んでいたのは、コーディングでもテストでもありません。 「概要設計書をAIに書かせる」 ——つまり、開発の上流工程そのものでした。 「AIでコーディングを行い、テストを行うのは当たり前になりつつある。じゃあ今、AIの導入が遅れている場所はどこか。そう考えていくと、上流工程が残るんです」 この記事はこのような方におすすめです。 コーディングやテストのAI活用は進んだが、その先の伸びしろが見えなくなっている方 仕様が固まりきらない案件で、設計ドキュメントの書き直しに疲弊している方 AIツールの選定・比較検討に時間をかけすぎていると感じている方 速くすること自体が目的ではありません。空いた時間を何に使うのか？ぜひ考えるきっかけになると幸いです。 AIが入っていない場所を探したら、上流工程が残った 前田さんが所属する楽楽販売の開発チームでも、コーディングやテストコード生成でのAI活用はすでに日常の一部になっています。 課題として浮かび上がったのは、 開発プロセス全体で見たときのボトルネックの位置 でした。 「上流工程が遅延すると、結局、開発タスクが下に降りてこないんですよ。下流だけをどれだけ速くしても、そこは詰まったままになる。ボトルネックは上流工程にあると感じました」 コーディングが2倍速くなっても、その前段の設計に時間がかかっていれば、リードタイム全体はほとんど変わりません。AIが入っていない場所こそ、一番効きやすい場所だった、ということです。 ここが今回の取り組みの出発点になりました。 なぜ「概要設計書」を選んだのか 上流工程といっても範囲は広い。その中で前田さんが最初の対象に選んだのが、概要設計書でした。楽楽販売の概要設計書には、少し特殊な事情があります。 「楽楽販売の概要設計書は、事業部向けの説明資料も兼ねているんです。なので、普段はGoogleスライドで作成しています」 読み手が開発者だけではないため、ドキュメントには内容の正しさに加えて「説明資料としての体裁」が求められます。テキストベースの設計書に比べて、作成にも修正にも手間がかかりやすい構造です。 そして、今回対象にした案件は、 顧客の声から生まれた案件 でした。 顧客起点で始まった案件には、ひとつの特徴があります。解決すべき課題ははっきりしている一方で、それを どういう外部仕様で実現するかは、始まった時点では固まっていない ということです。 「具体的な外部仕様はハッキリとはしておらず、概要設計を何度も書き直すことになるのは明白でした」 書き直しは「起きるかもしれない」ではなく「明白だった」。この見通しが、次の判断につながります。 「書き直させる」前提で、最初からAIに書かせた 普通の順序であれば、まず人間が叩き台を作り、AIには補助的に手伝ってもらう、という発想になりそうなところです。前田さんは、その逆でした。 「最初からAIを使って書き、AIを使って書き直させる。そういう固い意思で概要設計を作り始めました」 使ったのは、Anthropicが2026年4月に公開した「 Claude Design 」です。テキストでの指示や対話を通じて、スライド資料やプロトタイプ、LPなどを作成できるツールで、執筆時点ではリサーチプレビューとして提供されています。前田さんはこれを使って、設計書のスライドそのものを生成しました。 前田さんの言葉で印象的だったのは、 「思いの外、精度が高いものが作れることに驚いた」 という点です。当初から成功を確信していたわけではなく、書き直し前提だからこそ試せた、という順序でした。 さらに効果が大きかったのは、修正フェーズだったといいます。 「『こういう修正をお願い』と言うと、全部のページに目を通して、修正すべき箇所を洗い出して修正してくれるんです。漏れなくやってくれる」 これは、スライド形式の設計書につきまとう典型的な問題に効いています。ページ数が増えるほど、一箇所の仕様変更が他ページに波及していることを見落としやすくなる。 「人間がやると、矛盾した記載が残ったりします。この辺はAIの方が優秀でした」 「速く書ける」だけでなく、 「書き直しても整合性が壊れない」 こと。書き直しが前提の案件においては、こちらの価値のほうが大きかったと言えそうです。 つまずいたのは、スライドのデザインとUIのデザインの混在 もちろん、すべてがうまくいったわけではありません。前田さんが最も苦労したポイントは、 スライドのデザインと、画面UIのデザインが、AIの中で混ざってしまう ということでした。 概要設計書では、新機能の画面イメージを説明する必要があります。つまり1枚のスライドの中に、 資料としてのレイアウト（見出し、余白、図解の配置） 説明対象であるプロダクトのUIデザイン という、性質の異なる2種類のデザイン情報が同居することになります。AIから見ると、この2つは区別しづらい。 結果として、UIの説明図がスライドの装飾に引きずられたり、その逆が起きたりします。 前田さんが出した結論は、 分業させる ことでした。 「UIのデザイン案は、別で作らせた方が早くて綺麗なものができそうです」 ただし、前田さんはこれを「常に分けるべき」とは言いません。 「ただ、まだまだ修正が入るフェーズなら、叩き台としてこれで良い、と妥協するのも必要だと思います。効率を考えて使い分けるべきですね」 ここは、AI活用の実務でかなり効く判断だと感じました。 「AIの出力品質をどこまで上げるか」ではなく「今このフェーズで、どこまで上げる必要があるか」から逆算する。 仕様が動く前提の段階で見た目を磨き込んでも、その労力の多くは次の書き直しで消えてしまいます。 ツール選定に、20分以上かけない 「なぜこの方法を選んだのか。他の選択肢と比較検討はしましたか？」 この質問への答えが、今回のインタビューで印象に残った部分でした。 「正直、こだわりはなかったです」 比較検討をしなかった、という話ではありません。前田さんが問題視していたのは、 比較検討そのものにかかる時間 でした。 「今はどんどん新しいツールが出るし、料金プランの変更も1ヶ月単位で発生し続けています。悩んでいる時間が、開発速度を鈍化させる」 半年かけて選定した最適解が、選び終わった頃には最適ではなくなっている。変化の速度が意思決定の速度を上回っている領域では、慎重な比較検討がそのままコストになる、という指摘です。 「闇雲にやれば良いとは言いません。ただ、例えば20分調べて良さそうなツールを見繕って、その中から自分が良いと思うものを選んで、実際にトライアンドエラーを始める。その方が効率的じゃないかと思います。今のラクスに求められているスピードは、そういうことだと思っています」 ラクスの行動指針には「小さく試して大きく育てる」という項目がありますが、この判断はまさにそれを地でいくものだと感じました。 机上で最適解を探すより、手を動かして得られる情報のほうが速くて確かだ という割り切りです。 なお、これは「検討を放棄してよい」という話ではないはずです。今回のケースでは、書き直し前提のドキュメント作成という 失敗コストの低い領域 から始めているという前提があります。試す場所の選び方とセットで受け取るのが実態に近そうです。 体感で2〜4倍。ただし数値化はこれから では、実際どれくらい速くなったのか。 「まだ概要設計は完了していませんが、速度も品質も段違いであることは明らかです。体感ですが、2倍〜4倍は早く仕上がります。数値化できていなくて申し訳ないですが……」 ここは、記事としてもそのまま正直に書いておきたい部分です。 現時点で計測された数値ではなく、進行中の案件における作業者本人の体感値 です。今後、案件が完了した段階で改めて振り返る余地が残っています。 一方で、前田さんが強調していたのは倍率そのものよりも、その手前にある事実でした。 「これまでAIが入っていなかった場所にAIが導入されるというのは、測れないくらいに改善効果が大きいと再確認しました」 すでにAIが入っているところをさらに磨いても、上がり幅はだんだん小さくなっていきます。一方で、ゼロだったところに入れたときの差は桁が違います。 伸びしろは、まだAIを使っていない場所にある。 これが今回の取り組みから得られた、最も再現性の高い学びだと感じました。 生まれたバッファは、顧客の声を拾う時間へ 最後に、他チームにも共有したいことを尋ねました。 「AIの進化で開発の現場が劇的に変化している昨今ですが、我々が求められている開発速度はこんなもんじゃない、と思っています。固定概念に囚われずに、もっと遥か高みを目指してほしいです」 そのために日々持ち続けたい問いとして、前田さんは2つを挙げてくれました。 手でやっている作業は、AIで代えられないか？ そもそも、やる意味がある作業か？ 後者が併記されているのが重要なところだと思います。AIで速くすることと、そもそもやめることは、別の打ち手です。前者だけを追いかけると、不要な作業を高速に生産し続けることになりかねません。速くした先に何を置くかも、はっきりしていました。 「無駄を省くことで生まれたバッファーは、顧客の声を拾う時間などに有効活用して、より良い、求められるものを作り出していきたいです」 今回の取り組みの対象になった案件そのものが、顧客の声から生まれたものでした。 顧客の声を聞く → 作る → その時間を捻出するために速くする → さらに顧客の声を聞く。 AI活用を、開発効率の話で終わらせず、顧客志向のサイクルを回す原資として位置づける。ここに、ラクスの開発組織がAIに向き合う理由が表れているように感じます。 まとめ 今回の取り組みから持ち帰れるポイントを、3つに整理します。 AI活用の伸びしろは、まだAIが入っていない工程にある。 導入済みのところを磨くより、AIが入っていない場所を探すほうが伸びしろは大きい 書き直しが確定している成果物は、AIとの相性が良い。 速さだけでなく「修正しても整合性が壊れない」ことの価値が効いてくる フェーズに応じて、品質の妥協ラインを決める。 仕様が動く段階で作り込んでも、その労力は次の書き直しで消える ラクスの開発本部では、「顧客に価値を高速提供できるAIネイティブな開発組織へ」という方針のもと、こうした現場発の試行錯誤を各チームで進めています。今回のように、まだAIが入っていない領域に踏み込む取り組みも、これから増えていくはずです。 最後までお読みいただきありがとうございました！