こんにちは、株式会社レイヤード（https://layered.inc/）の渕橋です。
最近、採用面談の場で「AI、どのように使ってますか？」と聞かれることが増えました。この記事では、開発チームの一員として、またエンジニアリング本部の副本部長として、私たちが実際にAIをどう使って開発しているのかを書いてみます。まだ試している途中のことも含めて紹介します。

はじめに

私たちがいま一番意識しているのは、AIを使って、開発の速度と品質の両方を上げることです。

AIを使えばコードを書くスピードは確かに上がります。でも、ただ速く書けることと、それを自信を持って本番環境へ送り出せることは、まったく別の話です。
コードを書く時間だけではなく、そこからレビューして、テストして、安心してリリースできるまでの時間を短くしたい。今はどうすればよいかを模索しています。

以下は、実際に私たちがどう開発しているかの具体的な内容です。

1. どのモデルを、どこで使っているか

コーディングエージェントは、Claude Code か Codex のいずれかを主軸に据えて開発しています。

会社として Claude Team プランを契約していて、利用状況に応じて妥当なプランを会社の費用で用意してもらえます。Codex を使いたい場合も、必要であれば ChatGPT の契約を会社費用で用意してもらえます。加えて、GitHub Copilot も併用しています。設計相談や技術調査には ChatGPT / Gemini などのチャットUIも使っています。

自社のAI基盤も用意しています。AWS上にRAG基盤を構築し、Amazon Bedrock を利用して、社内ドキュメントを根拠に回答を生成する仕組みを運用しています。汎用モデルに社外の一般論を答えさせるのではなく、自社の文書に紐づいた回答を返せる状態を、自分たちで作っているということです。

この領域は数か月単位で状況が変わるので、今のところ「これを使え」と一本化はしていません。ただ、チーム内で開発プロセスを標準化していく検討を進めている段階でもあり、その結果としてツールを揃えていく可能性はあります。最終的には、個人ごとの使いやすさよりも、チーム全体として開発しやすい形を目指したいと思っています。

2. AIが書いたコードを、どうレビューしているか

レビューについて全社で決めているのは、大枠のところだけです。

すべてのプルリクエストは、AIの一次レビューを経たあと、必ず人間のレビューを通す。

生成元がAIかどうかで例外はつくりません。ここはプロダクトを問わず共通です。

AIレビューを入れたからといって、人のレビューを軽くしているわけではありません。単純なミスや機械的に見つけられる問題を先にAIに見てもらって、その分、人はこの実装で本当にいいのかを考えることに時間を使う。順番を変えただけで、人が見る量を減らしたつもりはありません。人の手による動作確認も、変更の大小にかかわらず実施しています。

そのうえで、リスクの大きい変更には人の関与を上乗せします。

• 設計に無理がないか、考慮漏れがないかを、時間をかけて確認する
• テストを十分な量そろえる

AIでテストが書きやすくなった分、ここにはむしろ今まで以上に力を入れています。

どこから「リスクが大きい」と見なすか、何を上乗せするかは、プロダクトごとに違います。たとえばサブエージェントで観点を分け、多角的にレビューさせているチームもあります。ここは各チームが自分たちで組み立てています。

3. どこまでAIに任せ、どこから人間が責任を持つのか

任せている領域

• 実装コードの生成・リファクタリング
• テストの作成、失敗したテストの自動修正
• プルリクエストの一次レビュー・指摘
• 仕様・設計ドキュメントの作成

会社としてAI開発の推進方針を掲げているので、任せる領域は今後さらに広がっていくと思います。

人間が責任を持つ領域

ここは私たちの中で明確にしています。AIの出力にもとづく判断のすべてについて、最終的な責任は人間が負います。意思決定をAIに全面的に委任する設計にはしていません。AIの出力は、必ず人間が確認・検証する前提で運用しています。

とくに次の4点は、「人間の判断領域」として、動かしていません。

• アーキテクチャ・技術選定の判断（何を作るか、どう作るかの方向性）
• セキュリティ・個人情報の取り扱い
• 本番リリースの最終判断（出す／出さない）
• 顧客・事業への説明責任（「なぜこの実装なのか」を人間が説明できる状態を保つ）

「AIが書いたので分かりません」が成立してはいけません。AIが書くコードが増えても、この責任までAIに渡すつもりはありません。

4. 個人の工夫を、チームの資産に変える

AIへの指示書となるルールファイル（CLAUDE.md 等）は、チームで共有して、継続的に改善しています。個人が見つけた良い進め方を個人の中で終わらせず、リポジトリの資産として残していく運用です。

そのうえで、エンジニアリング組織全体で知見やプロンプトを活発に共有していける体制づくりに着手しているところです。社内でのAI利用ルールも現在整備中です。ルールを明確にすることで、安全にAI活用を推進できる環境をつくることが目的です。「これはダメ」を増やすというより、「ここまではやっていい」を分かりやすくしたいと思っています。それによって、現場でAIを使いやすくなるはずです。

正直、ここはまだ完成形とは言えないと思っています。AIの活用レベルはどうしても個人差が出ますし、使いこなせている人のノウハウが組織全体にうまく浸透しきれていないのが現状です。だからこそ、ここから先は一緒に知恵を絞って形にしていける、一番面白い伸びしろがある部分だとも感じています。

5. AI時代のエンジニア像

各ツールの使い方ももちろん大事ですが、最近はそれ以上に、出てきたものをどう扱うかが重要だと感じています。
AIが書いたコードをどこまで信用するのか、人がどこまで確認するのか。チームの中でも、まだ日々やり方を変えています。

私自身、まだこの線引きに完璧な答えを持っているわけではありません。ただ、今のところ、とくに大事だと思っているのは次の4つです。

① AIが書いたものでも説明できること

• AIが書いたコードでも、「なぜこの実装なのか」を自分の言葉で説明できる
• 「AIに任せていい」と「自分が見るべき」の境界を、状況ごとに自分で判断できる

② 出力をそのまま信用しないこと

• AIの一次レビューを鵜呑みにせず、「本当にこれで合っているか」を自分の目で確かめられる
• 生成されたコードを「読める」だけでなく、「疑える」

③ うまくいったやり方をチームで回すこと

• 良いプロンプトやCLAUDE.mdの改善案を、自分のメモで終わらせずリポジトリに残せる
• 他の人のやり方を取り入れることにも抵抗がない

④ 正解のない問いを楽しめること

• 「まだルールがない」を、余地と捉えられる
• AI活用のベストプラクティスを、誰かが決めるのを待つのではなく一緒に作っていく

最後に

私たちは、AIを「導入した会社」になりたいわけではありません。AI前提で開発プロセスをどう組み直すかを、実際に手を動かしながら考え続けている会社です。

まだ完成していない部分も含めて書いたのは、それが今の私たちのリアルだからです。もしこのあたりの話に興味があれば、ぜひ面談でお話したいです。実際に今どんなことをやっているのか、もう少し具体的な話もできると思います。

アプリ開発エンジニア

自社のRAG基盤も自分たちで作る。AI活用に本気な医療DX企業

私たちは、医療機関と患者の接点となる領域において、予約システム、WEB問診、IVR（電話自動応答）、患者管理システムなどの医療DXサービスを総合的に提供している企業です。 現在、全国5,000施設以上の医療機関に導入され、月間数百万人の生活者にご利用いただいています。 私たちのミッションは、医療者と生活者の接点である「医療インターフェイスの研究と実装」です。両者の間に立ち、コミュニケーションをより滑らかで最適なものへと変革していくため、日々プロダクトやソリューションの開発・提供に挑んでいます。 ＜主な事業領域＞ 1｜医療機関向けクラウドサービスの開発・運用 問診・予約・電話応答・患者管理など、日々の実務に直結する業務をデジタル化し、医療機関の負担軽減と運用改善を支援します。 ・WEB問診「Symview」 ・予約システム「Wakumy」 ・電話自動応答システム「Iver」 ・患者管理システム「Kakarite」 2｜医療コンテンツの制作（動画・デジタルサイネージ等） 専門知識が必要な医療情報を、患者にとって“わかりやすい形”にデザインし、伝えるソリューションを提供します。 ・クリニック向け動画サービス「Medicastar」 3｜医療機関の業務改善・運用サポート レイヤードはプロダクト・ソリューションをつくって終わりにはしません。医療現場でしっかりと活用してもらえるようになるまで責任をもって伴走します。 医療現場をよく理解し、現場で活用できるプロダクト・ソリューションをつくり、現場に定着するまで責任をもつ。そのプロセスを経て、ようやく私たちが大切にしている「カスタマーサクセス」が実現します。

株式会社レイヤード