こんにちは、メルペイiOSエンジニアのkubomiです。 この記事は Merpay & Mercoin Tech Openness Month 2026 の 10日目の記事です。 生成AIによって、エンジニアが短時間でプロトタイプをつくれる場面はかなり増えました。最近、小規模なプロジェクトで「初回ミーティングの前に、動くものをつくり切ってしまう」という進め方を試したところ、意思決定のスピードが劇的に変わりました。私はこのやり方を "Build First, Discuss Later（まずつくる、議論は後）”と呼んでいます。この記事では、その具体的な進め方と、実践を通じて私自身に起きたマインドセットの変化を紹介します。 よくある開発フローと、その課題 私たちの現場では、開発に取りかかる前に、まず関係者の認識をそろえておくのが一般的です。具体的には、最初にプロダクトマネージャー（PdM）が大まかな仕様を用意し、それをもとにキックオフミーティングを開いて詳細を議論します。議論を経てPdMが仕様を固め、エンジニアはその仕様をもとに見積もりを出して実装に入ります。 ただ、議論して仕様を固めたつもりでも、いざつくり始めると「あれ、ここの挙動どうするんだっけ？」という疑問が次々と出てくることがあります。そのたびにPdMへ確認したり、追加のミーティングを開いたりすると、少しずつコミュニケーションの往復が増えていきます。 "Build First, Discuss Later" という提案 そこで私が実践したのが、プロセスの順番をあえて逆転させる "Build First, Discuss Later" です。仕様が固まる前に、まず動くプロトタイプをつくってしまうという発想で、ミーティングはその動くものを土台に議論を進めます。 従来は「議論して仕様を固めてからつくる」流れでしたが、これを「先につくり、その動くものを見ながら議論する」へと入れ替えます。実際に触れる画面があると、抽象的な仕様書をめぐる議論よりもはるかに早く、関係者の認識がそろっていきます。 ただし、何にでもこの進め方を使うわけではありません。何日もかかるような大きな実装でこれをやると、方針が変わったときの手戻りが大きすぎます。私の場合は、数時間から1日以内でつくれるくらいの小規模な施策に限定しています。そのくらいの規模なら、悩んで待つより、とりあえずつくってしまったほうが圧倒的に速い、という実感があります。 ミーティングにプロトタイプを持ち込む3つのステップ 私は "Build First, Discuss Later" を、ミーティングの前・中・後という3つの場面に分けて実践しています。ここでは、アプリの画面にバナーを追加した事例を例に、それぞれの場面で意識していることを順に紹介します。 ミーティング前：自分のベスト案でつくり切る ミーティング前は、手に入る計画書や仕様書をAIと一緒に読み込み、「なぜつくるのか（Why）」「何をつくるのか（What）」を自分なりに解釈します。この段階で最も大事なのは、完璧な実装をつくることではなく、どこが曖昧なのかを目に見える形にすることだと考えています。実際、詳細が決まっていないことがほとんどですが、曖昧な点にぶつかっても立ち止まりません。PdMに質問する代わりに、いったん自分が考えるベストな案でつくり切り、迷ったポイントはミーティングのアジェンダに整理しておきます。 たとえば、バナー追加の事例では、リリースに必要な最小限の機能に絞って早くリリースするか、将来使い回せる再利用性を優先するか迷いながらも、まず最小限の機能で動くプロトタイプをつくりました。UIデザインがまだない場合も、既存の画面部品を組み合わせた仮の見た目で形にしました。 ミーティング中：動くものを見ながら論点を解消する ミーティング中は、その動くプロトタイプを見せながら議論し、可能な限りその場で論点を解消します。意見が分かれそうな箇所には、あらかじめA案とB案を用意し、「私はこういう理由でA案を推します」と推奨案まで添えておきます。バナーの例では、期日を踏まえて、リリースに必要な機能に絞った設計プランと、将来の再利用まで見据えた設計プランを提示し、PdMはその場で前者のプランに合意できました。細かな仕様も、プロトタイプを見ながらサクサクと決まっていきました。判断の材料がそろっているため、議論は驚くほど早く前に進みます。 ミーティング後：決まった内容をすぐ反映する ミーティング後は、決まった内容を仕様書に反映し、実装を微修正したうえで品質保証（QA）のテストに回します。大きなつくり直しが起きにくく、初回ミーティングの直後にはリリースが見えている、という状態になりました。バナーの例では、私がつくった仮の見た目をデザイナーが本番デザインへブラッシュアップし、実装側はそれを反映する微修正で済みました。 "Build First, Discuss Later" で起きた3つの変化 この進め方を試してみると、ミーティングの進み方やPdMとのやり取りがかなり変わりました。特に大きかった変化は、次の3つです。 1つ目は、ミーティングがほぼ1回で完結するようになったことです。うまくいけば、初回ミーティングが終わった時点で仕様も実装もほぼ固まっており、開発見積もりすら不要になることもあります。その後の往復も大きく減りました。 2つ目は、議論が速く、かつ正確になったことです。実際に動くものを見せながら「この画面の挙動はこれでよいですか」と確認できるため、言葉だけのやり取りで生じがちな認識のズレが起きにくくなりました。 3つ目は、PdMの負担が軽くなったことです。エンジニアが具体的な仕様の案まで持っていくので、PdMは方針を確認するだけで済みます。特にPdMが複数プロジェクトを兼務しているような状況では、その確認コストを減らせるだけでも大きな価値があります。 「待つエンジニア」から「提案するエンジニア」へ こうした変化は、単に開発プロセスやコミュニケーションを効率化しただけでなく、私自身のエンジニアとしてのマインドセットにも影響を与えました。 以前の私は、決まった要件を正しく実装することがエンジニアの主な役割だと思っていました。けれど、PdMが持つWhyと大まかなWhatを起点に、まず動くものをつくってみると、「これは要らないかもしれない」「こっちの方がお客さまに価値を届けられるのでは」といった議論を、自分から持ち込めるようになりました。 いちばん大きかったのは、「私はこれがいいと思う」というアイデアを持ってミーティングに参加できるようになったことです。ただ仕様を待つのではなく、要件定義の段階から意見を出し、仕様を決めていく側に少しずつ入っていけるようになりました。 そうやって関わっていると、「この機能は今いちばん自分が詳しい」というオーナーシップも自然と生まれてきます。自分の提案が仕様に反映され、動くものを通じてプロダクトの方向性が決まっていく。その過程に関われるようになって、プロダクトづくりが前より一層楽しくなりました。 生成AIによって「まずつくってみる」ハードルが下がったことで、エンジニアが上流の議論に入りやすくなったと感じています。プロトタイプをつくってミーティングに持ち込むことは、単に開発を速くするだけではなく、エンジニアがより主体的にプロダクトづくりに関わるためのきっかけにもなるのだと思います。 まとめ "Build First, Discuss Later" は、先に動くプロトタイプをつくり、それを見ながら議論することで、意思決定を速くする進め方です。みなさまも、「仕様待ちで開発が始められない」「仕様が曖昧で手戻りが多い」と感じたら、自分なりのプロトタイプを会議に持ち込んでみてください。会話が前に進むだけでなく、プロダクトづくりの楽しさも少し違って見えてくると思います。 次の記事は mewutoさんです。引き続きお楽しみください。

こんにちは、ラクス技術広報です。 AIツールが開発現場に届いたあと、何が起きているのか。ChatGPT EnterpriseやGitHub Copilotが展開されてしばらく経ったころ、ラクスの開発本部横断組織「開発管理課」はある問いに詰まっていました。ツールは使えている。使っているエンジニアもいる。でも組織として本当に生産性が上がっているのか、確かめる手段がなかった。 実際に声を集めてみると、大きく個人差が開いている状況でした。AIを使いこなしてどんどん先へ進む人と、今まで通りのやり方を続ける人。「チームによって開発スピードに差が出てきている。個人の問題というより、組織として型がないことが課題だと感じていた」と担当者は言います。 ラクスは楽楽精算・楽楽明細・楽楽自動応対など複数のクラウドサービスを展開しており、開発組織は商材ごとに独立したチームで構成されています。チームが独立しているぶん、AI活用のやり方も自然と各チーム任せになりやすく、活用度にムラが出やすい環境でもあります。このムラをどう埋め、組織全体に浸透させるか。開発管理課がどう向き合っているのかを、担当者に語ってもらいました。 まず「測る」ことを設計した 「使わない」には、それぞれの理由があった AI活用は確かに進んだ。でも、浸透しきってはいない 顧客に届けるための、AI活用標準化 今期進める4つの取り組み 「エンジニア非稼働時間帯でも開発が進む」を目指して まず「測る」ことを設計した 「浸透しているかどうかが見えない」問題を解くために、開発管理課が最初に選んだ一手は計測の仕組みを作ることでした。 参考にしたのはSalesforceが実施していた48項目にわたるAI浸透度調査。ただ、そのまま導入するのは規模が大きすぎる。削り込んでいっても20問ほどになってしまい、それでもまだ多い。さらにラクス特有の難しさがありました。ラクスの開発組織は商材ごとにチームが独立しており、技術スタックも文化も異なる。単一組織向けに設計されたサーベイをそのまま当てはめても、実態を正しく測れない。加えて「どのツールを使っていますか」「その機能は使っていますか」という質問は、ツールや機能が変わるたびに使えなくなる。「変わらない計測軸で、AI導入を継続的に観測するにはどうすればいいか」という問いに、担当者は上長と二人で揉みに揉みました。 行き着いたのが「プロセス別AIコミット度」という設計軸です。実装・テスト・設計・要件定義といった各開発フェーズで、どれだけAIを活用しているかを問う。ツールの名前ではなく「工程への組み込み度合い」を問うことで、環境が変わっても変わらない比較軸を持てるようになりました。これにより、管理職への相談も「感覚値」から「数値に基づく議論」に変わっていきました。 第1回サーベイを実施すると「一歩目を踏み出せていない人が一定数いる」ということが数字としてはっきりしてきました。次の問いは「なぜ使われていないのか」でした。 具体的な計測設計については、2026年1月開催のイベントで詳しく発表しています。 speakerdeck.com 「使わない」には、それぞれの理由があった サーベイを取りながら、担当者は管理職や現場メンバーへのヒアリングも重ねていました。すると、「使わない」には想像以上に多様な事情があることが見えてきました。 担当者の印象に残っているのは、こんな声でした。 「"AI活用してます"とは言いにくい」 エンジニア文化特有の謙遜として、「AIちょっとできます」と名乗ること自体への抵抗感がある。「使っている」と言うのが気恥ずかしく、結果として使っていないように見えてしまう人が一定数いた。 「ハルシネーションでテストが増えて、むしろ手間が増える」 AIを入れると今まで動いていたコードがずれてしまい、テストの修正コストが上回る。「わざわざAIに作り直させると余計に手間が増える」と感じている人がいた。 「試行錯誤の時間が取れない」 高負荷な業務を抱えながら、AIを自分の業務にフィットさせる時間が取れない。「失敗したらまた手直しもしなきゃいけない。片手間でなんとかするのは難しい」という声もあった。 「AIとチャットはするけど、開発業務で効率的に使う方法がわからない」 AIとやりとりすること自体はしている。でも、実際の開発のどの場面でどう使えばいいかイメージが持てず、業務への組み込みは試せていない。気づけば「使っていない人」になっていた。 こうした声を踏まえ、「まず一歩目を踏み出せていない人をケアする」という方針で勉強会を設計しました。GitHub Copilotのベンダー開発者を招いたQA付きセッション、社内のAI推進者によるClaudeの活用ハンズオン。ハンズオンでは「AIとチャットするだけでなく、実際の業務にどう組み込むか」にフォーカスしたプレゼンを行い、参加できなかったメンバーのために動画も社内に公開しました。「特にあまりAIに触れていなかった方々からは『ためになりました』という声が届きました」と担当者は振り返ります。 AI活用は確かに進んだ。でも、浸透しきってはいない 2025年9月の第1回から約5ヶ月後、2026年2月の第2回サーベイでは、開発本部全体のAI生成比率が約15ポイント上昇（43.3% → 58.3%）。「生成比率75〜100%」と回答したエンジニアの割合も30%から50%以上に増加し、AI活用が個人の試みから組織的な広がりに変わってきた手応えがあります。 一部のチームでは、より具体的な成果が出ています。 コミットからマージまでのサイクルタイムが、以前の数分の1以下に短縮された 実装工程の大部分をAIが生成するようになった（実装工程のAI生成比率は60%台から70〜90%台に到達） リリース頻度が倍近くに上がった 「仕様駆動開発（SDD）」の導入で、ある工程の工数が半分以下になった テスト項目書からE2Eテストを自動生成する取り組みで、テスト工程も大幅に削減できた 楽楽明細・楽楽自動応対チームなど一部チームでは、要件定義・概要設計といった上流工程でのAI活用率も20%台から50〜60%超に向上。設計フェーズでもAIが機能する段階に入ってきています ただ、組織全体を見渡すと、AIはまだ浸透しきっていません。商材や個人のスキルによって、活用度にムラがあります。AI活用が進んでいるチームのやり方は、そのチームメンバーの体に染み込んだ暗黙知になっており、「隣のチームでも再現したい」となったとき、そのままでは届きません。「何ができるか」を検証するフェーズは超えた。「組織全体にどう行き渡らせるか」が、今期のスタート地点です。 顧客に届けるための、AI活用標準化 なぜAI活用を組織として標準化するのか。答えは「開発を速くしたいから」だけではありません。 ラクスの開発組織が最も重視している価値観は「顧客志向」です。顧客が抱える業務課題を深く理解し、それを解決するプロダクトを届けること。個人のAI活用では、顧客への価値提供スピードを「組織として」上げるには不十分です。一部のチームの開発スピードが上がっても、全体が変わらなければ、顧客が受け取る価値の差分は限定的です。だからAI活用を「組織の標準」にする必要があります。 AI活用が進んでいるチームを観察すると、スキルや知識だけでなく「どの工程で・どんなインプットを渡せばAIが機能するか」という設計が体に染み込んでいます。これは情報共有だけでは伝わりません。型化の優先順位は「顧客価値に最も直結する工程」から決めています。 今期進める4つの取り組み 以下の4つの取り組みを通じて、全商材で高速かつ高品質な開発プロセスを再現性のある形で確立していきます。 ① AI駆動開発手法の標準化 設計・実装・レビュー・テストで、なるべくエンジニアの介入が要らないAI活用の「型」を統一します。成果が出ているチームの事例を収集済み。仕様駆動開発の型化が進行中。 ② 商材特性に応じた最適化 各工程でのAI駆動開発を磨き込み、より精度の高いAIワークフローを実現します。商材・技術特性に応じて使い方を順次アップデートしていきます。 ③ ナレッジの体系化・横展開 成功・失敗を含む実務レベルの知見をガイド化し、誰でもアクセス可能な形で集約します。キャッチアップの土台を整備し、勉強会支援や情報共有の場も整えていきます。 直近のハンズオン会アンケートでは、「他チームとの密接な情報共有がほしい」という声が50%に上り、事前に最多と予想されていた「技術的なトレーニングやワークショップが必要」と同数でした。知識を増やすことと同じくらい、「隣のチームが何をしているか」を知ることが求められています。 ④ AI活用の浸透度・生産性の可視化 「測れないものは改善できない」という考えから、AI活用の推進状況を可視化する仕組みを整備しました。開発・インフラ・QA・PdM・PDを対象に、各工程でのAI活用状況を定義した「AI活用実践カタログ」です。定性的な「なんとなく進んでいる」から、「ここが遅れている、だから次はこうする」という定量的な議論への転換を目指しています。 「エンジニア非稼働時間帯でも開発が進む」を目指して 一部のチームでは、エンジニアが設計に集中している間にAIが実装を進める状態が見えてきています。非稼働時間帯も開発が動く。そのゴールの射程が、ようやくリアルになってきました。 ただ正直に言うと、型が定まっていない領域はまだ多く、ナレッジの体系化も道半ばです。それでも「組織全体にどう行き渡らせるか」という問いに正面から向き合えるタイミングになってきた、と感じています。 この取り組みについて、もう少し詳しく聞いてみたいという方には、7月15日（水）開催のオンラインイベントの視聴をご検討ください。CTOや執行役員をはじめ複数のエンジニアが、複数プロダクト組織でのAIネイティブ化の実践をリアルに語る場です。無料・オンラインで参加できます。 「CTO登壇」RAKUS AI Conference 2026 Summer

セガサミーホールディングス株式会社は、エンタテインメントコンテンツ事業、遊技機事業、ゲーミング事業の 3 つの事業領域を軸に展開する総合エンタテインメント企業グループの持株会社です。同社では、グループ会社であるサミー株式会社の基幹業務システム（販売、調達、生産、在庫管理）を支えるデータベースを、オンプレミスの Oracle Database から Amazon RDS for Oracle に移行しました。本ブログでは、移行の背景にあった課題、移行の取り組み、そして移行後に得られた効果についてご紹介します。 移行対象のシステム 今回の移行対象のデータベースは、サミー株式会社の基幹業務（販売、調達、生産、在庫管理）を支える複数の業務システムのバックエンドとして利用されていました。その大部分を占めるのが intra-mart を開発基盤とした基幹システムです。intra-mart の AP サーバーおよびデータベースはオンプレミス環境で運用されており、今回のプロジェクトで AP サーバーとデータベースの双方を AWS に移行しました。データベースには約 4,000 のテーブル、約 650 のマテリアライズドビュー、約 600 のプロシージャが存在し、データサイズは約 2TB に及びます。基幹系システムであるため、月次メンテナンス日以外は無停止での稼働が求められていました。 課題 当該システムをオンプレミスで運用する中で、大きく 3 つの課題がありました。 物理制約と調達遅延 オンプレミス環境では、リソース拡張にサーバーやストレージの事前購入が必要で、調達に時間がかかるため、事業や環境変化への即時対応が困難でした。初期投資の負担も大きく、突発的な負荷変動にも即座に対応できない状況でした。加えて、ハードウェア障害時には長時間のダウンタイムをともなうリスクがあり、DR/BCP 対策の強化も容易ではなく、基幹系システムとしての可用性に懸念を抱えていました。 運用負荷 監視ツールは自社で選定・管理する必要があり、開発・テスト環境の構築にもインフラ担当への依頼が必要でした。物理機器の保守やハードウェアのライフサイクル対応（リプレイス作業）にも工数を割かれ、月次メンテナンスなど業務時間外の対応も発生していました。こうした定型的な運用業務に時間を取られ、インフラ担当者が本来注力すべき高度な業務に集中しにくく、モチベーションの維持も難しい状況でした。 AI 活用を見据えた拡張性の確保 同社では、グローバルレベルでのデータ基盤強化とデータ利活用の促進、AI 活用による業務効率化を IT 戦略として掲げていました。将来的な AI 活用やデータ分析の推進を見据え、周辺サービスと柔軟に連携できる環境への移行も視野に入れていました。 ソリューション これらの課題を解決するため、オンプレミスのデータベースをクラウドへ移行する方針が決定されました。移行先として AWS に加え Oracle Cloud Infrastructure（OCI）やオンプレミスの継続も検討しましたが、以下の理由から AWS 上のマネージドサービスである Amazon RDS for Oracle を採用しました。 同一エンジン（Oracle）のマネージドサービスへの移行であるため、アプリケーション改修を最小限に抑え、移行コストを低減できる マネージドサービスの活用により、バックアップやパッチ適用などの運用負荷を軽減し、DR/BCP 対策の強化やリソースの柔軟な拡張が実現できる AWS 上にデータベースを配置することで、ETL、分析基盤、AI/ML など AWS の周辺サービスとの連携が容易になり、データ利活用の推進基盤として活用できる また、同社ではクラウドファーストを会社の方針として掲げており、コスト最適化およびマネージドサービス活用による運用効率の向上を推進していたことも、今回の移行を後押ししました。 移行スケジュール 移行は以下のスケジュールで実施しました。 プロジェクト計画フェーズ 移行に先立ち、2025 年 2 月中旬から 3 月末にかけてプロジェクト計画を策定しました。本プロジェクトは Oracle 11g から 19c へのバージョンアップも兼ねていたため、AWS Schema Conversion Tool（SCT）を使用してスキーマの互換性を事前に検証しました。これにより、DB オブジェクトの互換性に関する課題を早期に把握することができました。 また、Amazon RDS for Oracle に向けて対応が必要な箇所や影響範囲の洗い出しを行った結果、帳票出力や SQL Loader によるデータロードなどに影響があることが判明しました。帳票出力については、オンプレミス環境でファイルシステムにマウントして出力していた処理を変更する必要がありました。また、SQL Loader によるデータロードについても同様に影響がありました。いずれも Amazon RDS と Amazon S3 のインテグレーション機能を活用する方式に置き換えて対処しました。S3 インテグレーションへの切り替えは当初想定よりも対応範囲が広かったものの、方針が固まってからはスムーズに進めることができました。 加えて、オンプレミスからクラウドへの移行にあたっては、ネットワークレイテンシーの影響が懸念されました。検証ではデータ量に応じてレイテンシーが増加する傾向が見られましたが、最も遅延の影響を受けやすく、データ量が比較的小さい工場システムで問題がないことを確認し、移行可能と判断しました。 テストフェーズ 2025 年 8 月中旬から 11 月末にかけて、主要業務の SQL を対象としたシステムテストを実施しました。約 8 件の SQL でパフォーマンスの劣化が確認されました。原因は、移行先の Oracle バージョンでオプティマイザが生成する実行計画が最適ではなかったことにありました。この問題には OPTIMIZER_FEATURES_ENABLE パラメータのヒント句で対応しました。OPTIMIZER_FEATURES_ENABLE は、オプティマイザの動作を指定したバージョンの挙動に合わせるパラメータです。移行元のバージョンを指定することで移行前と同等の実行計画が生成されるようになり、性能劣化の大部分を解消しました。 移行実施 2025 年 12 月末に本番移行を実施しました。約 4,000 テーブル・約 2TB の基幹 DB を EXP/IMP で移行しました。本番切替後にも、事前テストでカバーしきれなかった一部の SQL でパフォーマンスの遅延が発生しましたが、テストフェーズで OPTIMIZER_FEATURES_ENABLE によるワークアラウンドを把握できていたため、同じ対処で速やかに改善することができました。それ以外に大きな問題は発生せず、基幹業務システムとしてスムーズに稼働を開始しました。DB が AWS 上に移行されたことでネットワーク構成が改善され、移行前と比較してパフォーマンスの向上も実感できる結果となりました。 導入効果 Amazon RDS for Oracle への移行により、以下の効果が得られました。 パフォーマンスの向上 移行により明らかにパフォーマンスが向上し、日次夜間バッチの処理時間も約 22% 短縮されました。高負荷時に遅くなる事象が解消され、サーバーダウンにつながるような負荷の問題もなくなりました。また、最適なリソース選択が容易になり、ワークロードに応じた適切なインスタンスサイズを柔軟に選択できるようになりました。 柔軟性の向上 AWS への移行により、数分でリソース拡張が可能になり、オンプレミス特有の物理制約や調達遅延が解消されました。突発的な負荷変動が発生した場合でも対処できる選択肢が確保され、事業や環境変化に対応できる安心感のある基盤を実現しました。初期投資についても、オンプレミスのようにサーバーやストレージを事前に大きく購入する必要がなくなり、利用量ベースで投資判断がしやすくなりました。さらに、別リージョンや別 AZ への設計を取り入れやすくなったことで、DR/BCP 対策の強化や事業継続性の向上にもつながっています。 運用効率の改善 監視は Amazon CloudWatch や Amazon CloudWatch Database Insights といった AWS のマネージドサービスに統合され、自社で監視ツールを選定・管理する必要がなくなりました。インフラ担当に頼らず、アプリ開発チームでも環境準備が可能になり、早期の環境構築が実現しました。月次メンテナンス時の再起動も不要になりました。オンプレミスの物理機器保守やハードウェアのライフサイクル対応（リプレイス作業）からも解放され、運用負荷が大幅に低下しました。こうした定型的な運用業務からの解放により、インフラ担当者のモチベーション向上にもつながっています。 データ利活用基盤としての拡張性 AWS 上にデータベースを配置したことで、ETL、分析基盤、AI/ML など AWS の周辺サービスとの連携が容易になりました。データベースを起点とした拡張性が高まり、IT 戦略として掲げるデータ利活用や AI 活用を推進するための基盤が整いました。 こうした効果を踏まえ、今回の AWS 移行についてセガサミーホールディングス株式会社の江田氏は以下のように振り返っています。 「移行により明らかにパフォーマンスが良くなりました。移行後は障害も発生しておらず、インフラ担当者が本来やるべき高度な業務に専念できる環境にシフトすることができました。」 – 江田 英昭 氏　セガサミーホールディングス株式会社 ITソリューション本部 ビジネスシステム部 部長 今後は、クラウドファースト方針のもと AWS のサービスや AI の活用を推進し、Amazon Redshift によるデータ分析をはじめ、グループ全体でのデータ利活用を拡大していく予定です。