AIに全力投資するLayerXでインターンしたら、実装が早すぎて設計の重要性に気づいた話

※本記事は、2026年5月までLayerXのAi Workforce事業部でSWEインターンとして活躍してくれたkawachan（かわちゃん）さんによる執筆です。本人のインターン期間終了に伴い、LayerX の koichi（こいち）が代理で投稿いたします。最先端のAI協業の現場で得られたリアルな学びを、ぜひご覧ください！

はじめに

こんにちは、kawachan（かわちゃん）です。昨年の12月から、LayerXのAi Workforce事業部SWE（Software Engineer）チームでインターンをしています。

この記事では、Ai Workforce事業部への応募を検討されている方や、当事業部に興味をお持ちの方に向けて、私たちがどのようにAIを活用し、協業しながら開発を進めているのか、インターン生としての実体験を交えてご紹介します。

私の業務内容

当事業部では、FDE（Forward Deployment Engineer）やプロダクトチームのメンバーから寄せられた意見や要望が、チケットとして起票されます。

インターン生もそのチケットの中から主体的に案件を担当し、設計、実装、テストまで一気通貫で行います。私は主に、Ai Workforceの既存機能の改善や、新バージョンに向けた新規機能の開発を担当させていただきました。

AIとの協業体制

Ai Workforce事業部SWEチームでは、AIを単なる補助ツールとしてではなく、強力な開発パートナーとして位置づけています。ここでは、具体的な取り組みをいくつか紹介し、チームの魅力をお伝えします。

1. 圧倒的なAIコーディングツールへの投資

LayerXでは「Bet AI」の行動指針の通り、CursorやClaude Codeといった最新のAIコーディングツールへの投資を惜しみません。私自身、週2日の勤務であるにもかかわらず、潤沢なAI利用環境を提供していただき、その投資の大きさに驚きました。

開発現場では、AIと壁打ちをしながら案件のドメイン知識を高速にキャッチアップし、まずはプロトタイプ（叩き台）を作成してチームへ共有します。認識のズレがあればその場で即座に修正していく、という高速なサイクルが確立されています。

これによりリリース速度が飛躍的に向上し、FDEを介してお客様のフィードバックが迅速に開発チームに届くため、さらなる改善へとつながる非常に良いサイクルが生まれています。AIを用いた高速な実装力は、これからの時代の必須スキルだと身をもって実感しました。

2. AIの活用を前提としたコーディング環境（rulesの運用）

AIにただコードを書かせると、チームのコーディング規約や設計方針を無視した実装になりがちで、結果としてレビュワーの負担が増えてしまいます。

この課題に対し、当事業部ではコードのドメイン知識や共通ルールをrulesというディレクトリに集約しています。AIの活用をはじめから前提として開発環境を整備している点が非常に合理的です。

AIは常にこのrulesを参照するため、チームの共通認識に沿った納得感のある実装方針を出力してくれます。また、開発メンバーは誰でも自由にrulesへ知見を追加・更新できるため、AIは常に最新のコンテキストに基づいた精度の高いコーディングを行ってくれます。

3. プルリクエスト（PR）の自動レビュー

必ずJSON形式で返してください。translation フィールドのみ。他のフィールド(technical_terms 等)は一切追加しないこと — 余計なフィールドを書こうとして本文翻訳がトークン上限で打ち切られる事故を防ぐため:

{"translation": "翻訳全文"}

開発の中で特に興味深かったのが、GitHub と Greptile や Devin などの AI ツールを連携させた、プルリクエストの自動レビューの仕組みです。

タスクによっては修正が 500 行を超える大規模なものもあり、人間によるレビュー負担が大きい場合がありました。そのような際、まずは AI が網羅的にレビューを行って細かなバグや規約の課題を潰します。これにより、人間のレビュワーはドメインロジックの妥当性やアーキテクチャの議論など、より本質的なレビューに集中できるようになりました。

4. QA ガイドおよび Story Test の自動生成

開発フローは、チケット起票 → 実装 → QA（品質保証）メンバーによる検証 → 本番リリース、という順で進みます。

私が参画して 1 ヶ月ほど経った頃、QA メンバーに提出するための「QA ガイド」を AI が自動生成する機能が導入されました。

これにより、開発者のドキュメント作成負担や QA メンバーの確認コストが軽減されただけでなく、開発者が「QA メンバーがどのような観点で検証を行っているのか」をより深く理解するきっかけになりました。結果として開発と QA の距離が縮まり、気軽に相談し合える文化がさらに強固になっています。AI には、部署間のギャップを埋め、チームの心理的距離を近づける効果もあるのだと実感しました。

インターンを通じて得た 2 つの大きな学び

1. 「どう作るか」より「何を作るか」の重要性

インターンを通じて最も強く感じたのは、開発現場において「これは本当に必要な機能なのか？」という本質的な議論が、技術的な実装方針の相談よりも圧倒的に多いことです。

AI の進化により、機能を作るコストは劇的に下がりました。だからこそ、「なぜ作るのか」「誰が求めているのか」「今本当に作るべきか」を深く熟考する重要性が増しています。

最近担当したタスクでも、まさにこのことを実感する出来事がありました。あるワークフロー作成機能において、「DSL（ドメイン固有言語）で定義するオブジェクト型のデフォルト値に対し、バリデーション（入力チェック）を強化する」という要件がありました。

しかし、SWE チームの社員の方々と相談し、実際の顧客のユースケースを深く検討する中で、「エラーを出してユーザーに修正を促す（バリデーションの強化）」よりも、「システム側でデフォルト値を自動補完する」方が、顧客の真の課題解決に繋がるのではないか、という議論に発展しました。

このように、言われたものをそのまま作るのではなく、「何を作り、何を解決したいのか」をチーム全体で常に問い直しています。ただがむしゃらにコードを量産するだけでは、使われない機能が増え、プロダクトの認知負荷やメンテナンスコストを高めるだけになってしまいます。FDE やビジネスサイドのメンバーと密に連携し、顧客の真の課題を捉え続けることが、今後の SWE にとって最も重要な役割になると確信しました。

2. 「AI 前提の開発」における設計の難しさと、エンジニアの新しい役割

LayerX は日本でもトップクラスに AI を活用している企業ですが、それでも「AI 前提の開発」は発展途上であり、新たな課題も見えてきました。

実装スピードが加速した分、設計が疎かになると技術負債が蓄積する速度も比例して早くなります。私自身、数週間前に実装した機能が開発のスピード感に追いつけず、すぐに負債化してしまう経験をしました。

AI が負債を残さず、いつでも切り離しや変更が容易なコードを書くためには、どのような設計やアーキテクチャが必要になるのでしょうか。従来の DDD（ドメイン駆動設計）などに代わる、AI 時代に適した新しいアーキテクチャパターンが、今後このチームの試行錯誤の中から生まれていくのではないかとワクワクしています！

おわりに

LayerX の Ai Workforce 事業部は、AI の可能性を最大限に引き出し、これまでにないスピード感で社会に価値を届けている非常にエキサイティングな組織です。

「AI が普及していく社会で、エンジニアとしてどう生き残るべきか」という不安を抱えている学生の皆さんにこそ、ぜひこの最先端の開発環境を体験していただきたいです。LayerX での SWE インターンへの挑戦を、心からおすすめします。