「開発会社の見積を見て、想定の3倍で驚いた」——シード直後のスタートアップ創業者から、いま最もよく聞く言葉です。プロダクトを立ち上げたい。あるいは、初期プロトタイプの次を作りたい。しかし、開発会社に相談したら「MVP でも 500〜1,000 万円」と提示され、資金調達額の 2〜4 割を初回開発だけで消費することに躊躇する——その場面で、多くの創業者が「フリーランスに頼めば 200〜300 万で作れるらしい」という噂を頼りに検索を始めます。
一方で、フリーランス発注で失敗した話も同じくらい耳に入ります。「要件が固まらないまま丸投げして炎上した」「連絡が取れなくなった」「作ったものが使い物にならず、結局作り直しになった」。安さと速さの裏返しにあるリスクは、初めて外注する立場の創業者ほど見えづらいものです。
やっかいなのは、「最初の外注」は一度きりの意思決定という点です。失敗すれば資金・時間・そして社内外の信用を同時に失います。次にやり直そうとしても、資金は減り、リリース時期は後ろ倒しになり、社内メンバーの発注に対する不信感まで残ります。だからこそ、この判断は「安いか高いか」ではなく「自社の状況に合っているか」で決める必要があります。
本記事では、スタートアップが最初の技術外注先としてフリーランスを選ぶべき5つのケースと、逆に選ぶべきでない4つのケース、そして発注後に失敗しないための最低条件までを、資金調達フェーズと要件明確度・社内PM機能・継続戦略の観点から整理します。最後に、「今の自社」がフリーランス発注に適しているかを判定できる 10 項目のセルフチェックを用意しました。読み終えたときに、「うちはフリーランスで進める」または「うちは開発会社にすべきだ」を社内で合意できる材料を手に入れていただくことがゴールです。
なぜスタートアップの「最初の技術外注」で失敗が許されないのか
「最初の外注」は、スタートアップにとって単なるベンダー選定ではありません。プロダクトの出発点そのものを他社に委ねる意思決定です。一度失敗すれば、次のリリース時期・資金繰り・社内の意思決定コストのすべてに波及します。ここではまず、「なぜ初回発注だけが特別に難しいのか」を分解しておきます。
開発会社の見積とフリーランス相場感の落差
一般的に、開発会社が MVP 案件で提示する見積は 500〜1,000 万円の帯に入ることが多く、要件定義・PM・デザイン・QA・インフラ設計を含めたフルスタック体制のコストが上乗せされます。一方、フリーランスに単職種で発注した場合の相場は、3 か月・単職種で 200〜500 万円程度です（体制や技術領域によって変動します）。
問題は、この落差が「安い vs 高い」ではなく「含まれているものが違う」という事実にあります。開発会社の見積には要件定義・PM・品質保証など複数の職能が含まれ、フリーランス単発の見積には基本的に「手を動かす部分」しか含まれません。この違いを理解しないまま金額だけで比較すると、後述の「要件が固まらない・PM が不在」という状態に陥り、フリーランスにも開発会社にも解決できない失敗パターンが生まれます。
参考として、秋霜堂の受託開発では MVP 2 か月・200 万円で立ち上げ、そこから月額 100〜300 万円で継続拡張していくパターンなど、フェーズごとの現実的な数値感を実績として持っています。予算感の解像度を上げる材料としてご活用ください。
「最初の外注」だけが持つ3つの構造的リスク
初回発注に特有の難しさは、次の 3 つの構造的リスクに集約されます。
- 社内知見ゼロによる評価の非対称性: 発注側にエンジニアリング経験が不足していると、見積の妥当性・技術選定の是非・進捗の遅れを見抜けません。悪意のないベンダーであっても、発注側が判断できないまま作業が進み、完成後に「思っていたものと違う」となるリスクが常にあります
- 再発注コストの非対称性: 一度失敗して別のベンダーに切り替える場合、既存コードの読解・引き継ぎ・データ移行に追加費用が発生します。ゼロから作り直したほうが速い、という結論になることも珍しくありません
- 信用の一度切り: 投資家・共同創業者・社内メンバーは「最初の外注判断」を経営者の意思決定能力の試金石として見ています。ここで大きく失敗すると、以降の開発判断で社内合意を取るコストが跳ね上がります
つまり、「最初の外注」はやり直しがきかない前提で設計する必要があります。次の章で、フリーランスと開発会社の構造的違いを整理し、そのうえで判断軸に入っていきます。
フリーランスと開発会社の「構造的な違い」を先に押さえる
判断軸を読み解く前に、両者が「何が違うか」を整理しておきます。ここを機能面（速い／遅い、安い／高い）で捉えてしまうと、後段の判断軸が抽象論に流れます。着目すべきは、契約構造・組織構造・撤退コストの 3 点です。
契約形態と指揮命令の違い
フリーランスへの発注は原則として「準委任契約」または「請負契約」を用います。準委任は業務遂行そのものに対価を払う契約、請負は成果物の完成に対価を払う契約です。ここで重要なのは、いずれの契約形態でも、発注者はフリーランスに対して指揮命令を行えないという点です。
指揮命令とは、「今日のこの時間にこの作業をせよ」「この方法で実装せよ」という具体的な業務指示を指します。これを行うと、契約上は業務委託でも実態が労働者派遣に近づき、「偽装請負」として労働関連法規に抵触するリスクが生じます。特にフリーランスに慣れていないスタートアップは、Slack で朝会に参加させたり、勤怠管理のような指示を出したりしがちですが、これは避けるべき運用です。
一方、開発会社に発注する場合、開発会社の社内 PM がチームを統率し、発注者は「何を作りたいか（What）」と「いつまでに欲しいか（When）」を伝える立場になります。指揮命令の責任は開発会社側にあるため、発注者は運用リスクを負いません。
職種の並列度・スケール余力・撤退コスト
フリーランスは基本的に「単職種の即戦力」です。フロントエンド、バックエンド、インフラ、デザイン、QA、PM——それぞれ別の人材を個別に契約することになり、各職種を同時に立ち上げるには発注者側の統率力が必要です。
開発会社は複数職種を一つのチームとして提供します。要件が拡大したら人員を増やす、途中でスキルセットの入れ替えが必要になれば社内で調整する、という柔軟性があります。ただし、その分の管理コスト・間接費が見積に含まれるため、単価は高くなります。
撤退コストも大きく違います。フリーランスは月次契約や案件単位契約が中心のため、合わないと感じたら比較的短期間で契約を終了できます。開発会社は多くの場合、最低契約期間や中途解約条項が定められており、想定外の撤退にはペナルティが発生することもあります。この違いは、要件が固まりきっていないフェーズでは「フリーランスの機動力」として機能し、要件が固まっているフェーズでは「開発会社の安定性」として機能します。
中間解の位置づけ（ラボ型・月額パートナー型）
「フリーランスでは足りないが、開発会社に丸ごと発注するほどではない」という状況では、中間解となる契約形態が有効です。代表的なものはラボ型開発（準委任で開発会社の専属チームを月額固定で借りるモデル）と、月額パートナー契約（社内の技術顧問・伴走型 PM を月次で稼働させるモデル）です。
ラボ型は「フリーランスに近い柔軟性 + 開発会社の複数職種体制」を両立します。フリーランスとの違い、選び方の判断基準についてはラボ型開発とフリーランスの違いにまとめていますので、深掘りしたい場合はあわせてご覧ください。
フリーランスを最初の外注先に選ぶべき5つのケース
ここからが本題です。フリーランス発注が「正解」となる 5 つのケースを、条件付きで整理します。抽象論ではなく、「自社がこの条件を満たしているならフリーランスで進めて大丈夫」という判定基準として読んでください。
ケース1｜MVP 前提でスコープを最小機能に絞れる
3 か月以内にリリースするコア機能が 1〜3 個に絞れており、UI/UX の凝った仕上げより「動くもので仮説検証したい」というフェーズであれば、フリーランス発注が最も費用対効果が高くなります。判断のポイントは「機能を削れるか」ではなく「削った状態でも仮説検証の目的を達成できるか」です。
このケースでは、フルスタックエンジニア 1 名または「フロント + バック」の 2 名体制で回すことが多く、開発会社に発注するとオーバースペックになりがちな職種（専任 QA・専任インフラ）を持たずに済みます。実際、秋霜堂でも新規 SaaS の MVP を 2 か月で構築し、その後の月額 100〜300 万円での継続拡張につなげた実績があります（コンサル業種の SNS マーケティング支援システム案件）。
MVP をフリーランスで進める場合の具体的な発注設計・要件整理の進め方については、MVP開発でフリーランスを活用する進め方で詳しく解説しています。
ケース2｜技術スタックが確定していて単職種で足りる
すでに社内で「フロントエンドは Next.js、バックエンドは Supabase」といった技術選定が済んでいて、追加開発が単職種で完結する場合は、フリーランスの即戦力性がそのまま活きます。技術選定を委ねる必要がないため、フリーランスに求めるのは純粋な実装スキルのみとなり、面談やコードレビューでの評価もしやすくなります。
逆に、「フロントエンドとバックエンドとインフラをまとめて考えたい」「そもそもどの技術を選ぶべきか相談したい」というフェーズでは、単職種のフリーランスは適していません。この場合は次章で扱う「開発会社に行くべきケース」に該当します。
ケース3｜社内に週次でレビュー・意思決定できる担当者がいる
フリーランス発注の成否を最も左右するのは、実は発注者側の PM 機能の有無です。週次スプリント（1 週間 = 1 イテレーション）を回す前提であれば、週に 1 回・1 時間程度のレビュー MTG を主催し、成果物を確認し、次週の優先順位を決められる担当者が社内に必要です。
この担当者は非エンジニアでも構いません。ただし「プロダクトの意思決定を持てる人」であることが条件です。「持ち帰って確認します」を繰り返すと、フリーランスの手が止まり、当初の低コスト・短納期のメリットが失われます。CEO や PdM が兼任することが多いポジションです。
秋霜堂ではアジャイル（週次スプリント）を全案件で採用しており、週 1 回の定例 + リアルタイムチャット対応をベースに、プロトタイプ→フィードバック→改善の高速サイクルで進行しています。この運用が回るのは、発注側にも週次で意思決定できる担当者がいる場合に限られます。
ケース4｜継続開発を前提とし、正社員化 or チーム化への切替パスが描けている
MVP でリリースして終わり、ではなく「うまくいけば継続開発する」と決めているスタートアップは、フリーランスとの長期関係を設計しやすくなります。具体的には、初回案件で相性を確認しつつ、うまくいけば正社員化を打診する、あるいは複数フリーランスを束ねてチーム化する、という切替パスを描いておくことです。
このパスが描けていると、フリーランスにとっても「単発案件ではなく継続関係の入り口」という位置づけになり、モチベーションと当事者意識が高まります。逆に、切替パスがないまま単発案件として発注すると、モチベーションが下がり、成果物の品質にも影響します。
ケース5｜予算 200〜500 万円で 3 か月以内に検証したい仮説がある
シード期の資金調達額が 3,000 万〜1 億円の範囲であれば、初回開発に投じられる現実的な予算は 200〜500 万円が目安です。この予算内で 3 か月以内に「作って、市場に出して、反応を見る」という仮説検証サイクルを回したい場合、フリーランス発注の機動力が最も活きます。
開発会社にこの予算感で MVP 一式を発注しようとすると、多くの場合「この予算では厳しい」という回答になります。理由は前述のとおり、開発会社の見積には要件定義・PM・QA・インフラ設計といった間接コストが含まれるためです。フリーランスであれば、これらを発注者側で肩代わりする代わりに、実装コストのみを支払う構造になります。
逆に、フリーランスを避けて開発会社に行くべきケース
前章で「フリーランスが正解となる 5 つのケース」を挙げましたが、実際には「フリーランスでは失敗する可能性が高い」ケースも存在します。ここに該当する場合は、資金面で無理をしてでも開発会社を選んだほうが結果的に安く済むことが多くあります。読者ご自身の状況に照らして、該当項目があるかを確認してください。
要件が未確定で上流工程から任せる必要がある
「何を作るべきか」がまだ言語化できていない状態で発注する場合、フリーランスは適していません。フリーランスは基本的に「決まった仕様を実装する」役割であり、要件定義・技術選定・スコープ判断まで任せられる人材は限られます。仮に見つかったとしても、単価は開発会社と大差なくなります。
要件定義から一緒に走ってくれるパートナーが必要なフェーズでは、開発会社への発注が現実解です。要件の言語化・優先順位付け・技術選定を含めた「上流工程のプロ」を持たない状態でフリーランスに丸投げすると、最終的に手戻りが発生し、当初の予算を超えることになります。
複数職種を同時期に必要とする
PM・デザイナー・フロントエンド・バックエンド・インフラ・QA を同時期に稼働させる必要がある場合、フリーランスをそれぞれ個別に契約する運用は現実的ではありません。契約管理・稼働管理・職種間の連携調整のすべてを発注者側が担うことになり、非エンジニアの創業者には荷が重い作業になります。
このケースでは、複数職種を一つのチームとして提供できる開発会社、または前述のラボ型開発が適切です。「単職種で足りるか」を最初に判断することが、外注形態選びの分岐点になります。
24 時間稼働・SLA 担保のある運用保守が発生する
サービス公開後に 24 時間稼働の監視・SLA（Service Level Agreement）に基づく応答時間保証が必要な業態では、フリーランスへの発注は難しくなります。単独のフリーランスは休暇・体調不良・並行案件などの理由で常時対応できるとは限らず、SLA 契約の履行主体になれないためです。
このケースでは、複数人のシフトで対応できる開発会社、または運用保守専門ベンダーの併用が必須です。B2B SaaS のように「顧客との契約で SLA を約束している」場合は、この観点を必ず優先してください。
業界特性で契約・情報漏洩リスクの重い担保が必要
金融・医療・行政・大手法人向けの受託開発など、契約書に厳格な情報漏洩条項・監査対応・PMS（プライバシーマネジメントシステム）認証・ISMS 認証が求められる業界では、個人事業主のフリーランスに発注することが実質的に難しくなります。
こうした業界では、法人格・認証取得・賠償責任保険加入を要件とする発注者が多く、フリーランスに委ねると発注者側が説明責任を果たせなくなるためです。該当する場合は、業界要件を満たす開発会社に絞って比較検討することになります。
フリーランス外注で「失敗しない」ための4つの最低条件
「うちはフリーランスでいける」と判断できた場合でも、発注運用が甘いと同じように失敗します。この章では、判断が正しくても実行で失敗しないための最低条件を 4 つ挙げます。逆に、これらを満たせない場合は「フリーランスが正解のはずだったのに失敗する」パターンに入り込みます。
スコープ・受け入れ基準を発注前に固める
フリーランスに発注する前に、スコープ（作る範囲）と受け入れ基準（どうなったら完成とみなすか）を書き出しておくことが不可欠です。粒度は「機能一覧を 1 ページに書き出せる」程度で構いません。「トップ画面のログインボタンを押すと、メールアドレスとパスワード入力のダイアログが開く」といったレベルで、実装完了の判定条件を言語化しておきます。
この準備を省略してフリーランスに発注すると、「この機能はスコープに入っていた／入っていなかった」の水掛け論が発生します。スコープ外の追加要望を受け入れる場合の追加費用ルールも、発注前に契約書に明記しておくべきです。
週次スプリント + 検収の運用リズム
前章でも触れたとおり、フリーランス発注では週次スプリント（1 週間 = 1 イテレーション）で回すことが標準運用です。毎週金曜に成果物を受け取り、月曜に次週の優先順位を決める、といったリズムを最初に決めておきます。
このリズムの利点は、認識ズレを最小 1 週間分の作業量に抑えられることです。月次で成果物を確認する運用にすると、認識ズレが発覚したときには 1 か月分の作業が手戻り対象になります。週次リズムは発注者側の負担が増えますが、失敗コストを大幅に下げる投資として捉えてください。
PM 機能を社内に確保するか、準委任で伴走型フリーランスに任せる
フリーランスに実装を任せる場合、PM 機能（要件整理・進捗管理・優先順位判断）は必ず社内または別の伴走型フリーランスに持たせる必要があります。実装フリーランスに PM も兼任させる運用は、契約上の指揮命令リスク・稼働圧迫による品質低下の両面で推奨できません。
社内に PM 機能を持てない場合は、準委任契約で「テックリード兼 PM」の役割を担うシニアフリーランスを別途契約することが有効です。単価は上がりますが、実装フリーランスの生産性が大幅に上がるため、総コストではむしろ抑えられることが多くあります。
契約書で NDA・IP 帰属・秘密保持・成果物受入条件を明文化
契約書の整備は、金額の大小にかかわらず必須です。特に次の 4 点は必ず明記してください。
- NDA（秘密保持契約）: 事業計画・顧客情報・技術情報の秘密保持義務と、契約終了後の存続期間
- IP（知的財産権）帰属: 成果物のソースコード・デザイン素材・ドキュメントの著作権が発注者側に譲渡されること
- 秘密保持と情報管理: リポジトリのアクセス権限管理・作業終了後のデータ削除ルール
- 成果物の受入条件: 検収の期限・受入テストの範囲・不合格時の再作業ルール
これらを口頭合意で済ませると、トラブル発生時に発注者側が守られません。テンプレートで構わないので、契約書として明文化することが最低条件です。契約書の雛形は、経済産業省・IPA が公開している「モデル契約書」（情報システム・モデル取引・契約書 第二版（IPA））を出発点にすると効率的です。
資金調達フェーズ別「最初の外注」推奨パターン
ここまでの判断軸を、資金調達フェーズごとの現実的なパターンに落とし込みます。「うちのフェーズならどう動くか」を具体化するための参考として読んでください。
プレシード期｜副業エンジニア・知人紹介中心（数十万〜200 万円台）
自己資金またはエンジェル資金で数百万〜1,000 万円程度を確保しているプレシード期では、初回開発に投じられる予算は数十万〜200 万円台にとどまるケースが多くあります。この予算帯では、正式なフリーランス契約より、副業エンジニアや共同創業者候補との「まずは 1〜2 か月試してみる」パターンが現実的です。
この段階では、成果物の完成度より「共同創業者になり得る人材との相性確認」を優先することが多く、外注というより「候補人材とのトライアル」に近い性格を帯びます。プロダクトを作ることそのものより、その先の体制構築を意識した発注設計になります。
シード期｜単職種フリーランス + PM 内製（200〜500 万円）
シードラウンドで 3,000 万〜1 億円を調達したフェーズでは、初回開発予算 200〜500 万円で単職種フリーランスに発注し、PM 機能は社内 CEO/PdM が持つパターンが最も一般的です。前述の 5 ケースがそのまま適用できるフェーズと言い換えられます。
このフェーズでは、MVP 2〜3 か月で仮説検証し、うまくいけば継続契約で拡張していく——という将来設計を最初から共有しておくことが重要です。フリーランス側から見ても「単発ではなく継続関係の入り口」として認識されるため、質の高い人材を確保しやすくなります。関連する意思決定の背景はスタートアップが正社員エンジニアを採らない理由にも整理していますので、体制設計を検討する際にあわせてご覧ください。
シリーズA｜ラボ型・月額パートナー中心、フリーランスは補完（500 万円〜）
シリーズA 以降で数億円を調達したフェーズでは、既存プロダクトの継続開発・複数職種の同時稼働・SLA 担保の運用保守が必要になるケースが増え、フリーランス単発では対応が難しくなります。この段階では、ラボ型開発や月額パートナー契約でチーム体制を借り、フリーランスは特定領域の補完人材として位置づけるパターンが主流です。
正社員採用と外部人材活用の比率設計・切替タイミングは、このフェーズで最も重要な経営判断の一つになります。CTO や技術顧問と連携しながら、事業成長の速度に合わせて体制を調整していくことになります。
発注前セルフチェック｜フリーランス発注が「今の自社」に合うか判定する10項目
最後に、これまでの内容を実行に移すためのセルフチェックリストをご用意しました。次の 10 項目に Yes/No で回答し、Yes の数で推奨パターンを判定してください。
10 項目のセルフチェックリスト
- 作りたい機能を 1 ページの機能一覧に書き出せている（またはすぐ書き出せる）
- 3 か月以内にリリースしたい仮説検証がある
- 必要な職種はフルスタック 1 名または「フロント + バック」の 2 名以内で足りる
- 技術スタックはすでに決まっている（または相談する必要がない）
- 週次 1 時間のレビュー MTG を CEO/PdM が主催できる
- 予算は 200〜500 万円以内で 3 か月程度を想定している
- うまくいけば継続契約や正社員化を打診する意思がある
- 24 時間稼働・SLA 担保のある運用保守は不要（またはまだ先の話）
- 業界特性上、契約主体を法人に限る必要はない（金融・医療・行政等ではない）
- 発注前に NDA・IP 帰属・受入条件を明記した契約書を用意できる
スコア別の推奨パターン
- Yes が 8〜10 個: フリーランス発注が最も費用対効果の高い選択肢です。単職種フリーランス + 社内 PM 機能の組み合わせで進めてください
- Yes が 5〜7 個: 中間解が適しています。伴走型フリーランス（テックリード兼 PM）を追加するか、ラボ型開発を検討してください。フリーランス単独で進めると、Yes になっていない項目が失敗要因になる可能性が高いです
- Yes が 4 個以下: 開発会社への発注を推奨します。フリーランス発注で失敗するリスクが構造的に高い状態です。特に「要件が未確定」「複数職種が必要」「上流工程から任せたい」のいずれかに該当する場合は、開発会社に相談したほうが結果的に安く済みます
このスコアリングは絶対的な基準ではありませんが、社内で外注方針を合意するための共通言語として機能します。CEO・COO・投資家・共同創業者との議論の起点として活用してください。
まとめ｜「最初の外注」は「事業判断」として扱う
スタートアップの「最初の技術外注」は、フリーランス vs 開発会社という単純な二択ではなく、フェーズ × スコープ × 社内リソース × 継続戦略の関数として捉える意思決定です。単価の安さだけでフリーランスを選び、要件が固まらないまま炎上する——このパターンは、発注者側が「安さ vs 品質」の軸で判断してしまうことで生まれます。
本記事で提示した 5 つの適合ケース・4 つの回避ケース・4 つの最低条件・10 項目のセルフチェックは、いずれも「自社の状況に照らして自己判断する」ための材料です。読み終えたときに「うちはフリーランスで進める」または「うちは開発会社にすべきだ」を社内で合意できていれば、この記事の目的は達成されています。
一発勝負の意思決定だからこそ、「なんとなく安いから」「知り合いに勧められたから」で決めず、事業判断として扱ってください。社内合意を取り、次のアクション（どんな人材に、どの契約形態で、どんなスコープで発注するか）を明確にした上で、最初の外注に踏み出しましょう。
関連情報
外部人材活用の意思決定に役立つ資料をご用意しています。発注前の判断軸整理・契約設計・体制構築を検討中の方は、お役立ち資料一覧からご自身の状況に合うものをご覧ください。
最初の外注先を「フリーランスか開発会社か」で決めきれない場合は、要件の整理段階からのご相談も承ります。詳細はお問い合わせフォームからお寄せください。
よくある質問
- フリーランス発注を始めた後、想定と違うと感じたら契約を途中で切り替えられますか？
月次契約が中心のため比較的短期間で契約終了できますが、引き継ぎ・データ移行コストが発生します。スコープと受け入れ基準を発注前に明文化し、週次レビューで早期に軌道修正できる体制を整えておくことが重要です。
- 良いフリーランスをどう見極めればいいですか？
技術スタックが確定していれば、GitHubの公開リポジトリでコミット履歴やテストコードの有無を確認し、面談では過去に同スタックで実装した機能の詳細と、選定理由を自分の言葉で説明できるかを問うと見極めやすくなります。技術選定から相談したい場合は単職種フリーランスでは評価軸を持てないため、開発会社や伴走型フリーランスへの相談を検討してください。
- 予算が200万円に届かない場合、フリーランス発注はあきらめるべきですか？
プレシード期で予算が数十万〜200万円台なら、正式契約より副業エンジニアや共同創業者候補との短期トライアルが現実的です。成果物の完成度より人材との相性確認を優先する発注設計に切り替え、限られた資金を使い切る前に体制作りの土台を固めてください。
- 指揮命令のルールを守りながら、実務上どう進行管理すればいいですか？
「いつまでに何を」という成果や納期の合意にとどめ、作業方法や作業時間の指示は避けてください。週次レビューMTGで進捗確認と優先順位決定を行う運用であれば、指揮命令に該当せず適法に進行管理でき、偽装請負のリスクも回避できます。
- 複数職種が必要でも開発会社に出せる予算がない場合、どうすればいいですか？
各職種を個別にフリーランス契約すると、契約・稼働管理や職種間の連携調整をすべて発注者側が担うことになり、非エンジニアの創業者には負担が大きく推奨しません。予算を抑えつつ複数職種体制を確保したい場合は、フリーランスに近い柔軟な契約形態と開発会社の複数職種体制を両立できるラボ型開発の活用を検討してください。
