「AIエージェントの作り方」を調べると、出てくるのは2種類の情報に偏っています。開発者向けフレームワークのチュートリアルか、ノーコードツールの操作手順です。しかし社内で企画を担う立場で必要なのは、そのどちらでもありません。自社の業務をどのルートで実装すべきか、その判断です。

ルートを決めずに手を動かし始めると、あとで作り直しになります。ノーコードで試作したものを本番に上げようとした段階で権限設計が足りないと分かる、あるいは自社開発に入ったあとで既製品で足りたと判明する。どちらも実際に起きます。判断を先にすれば避けられる手戻りです。

本稿では、AIエージェントを作る3つのルートを比較し、どの条件でどれを選ぶかの基準を整理します。あわせて、どのルートでも共通して必要になる設計、つまりツールの定義・ガードレール・人に戻す条件・評価の回し方を扱います。私たちは株式会社100として、HubSpot認定エリートパートナーの立場でCRMを軸にしたエージェントの設計・構築を支援しています。その工程で実際に決めている順序に沿って書きます。

AIエージェントを作るとは、何を作ることなのか？

最初に対象を確定させます。ここが曖昧なままツールを選ぶと、必要な工数を見誤ります。私たちが構築案件の初期に工数を出すときも、この分解から入っています。

最小構成の3要素は何か

OpenAIが公開している実務ガイドは、エージェントの最小構成を3つの要素に分解しています。Model（推論と意思決定を担うLLM）、Tools（行動を実行するための外部API・関数）、Instructions（振る舞いを規定する指示とガードレール）です（参考：OpenAI「A practical guide to building agents」）。

この3要素のうち、工数が読みにくいのはToolsです。接続先のシステムの数、書き込みを伴うかどうか、認証の方式によって作業量が数倍変わります。逆にModelの選定は比較的短く済みます。同ガイドは、まず最も能力の高いモデルで試作して性能の基準を作り、そこから小さいモデルに置き換えて許容できる結果が出るかを試す手順を推奨しています。すべてのタスクに最上位モデルを使う必要はないという整理です。

「作る」の前に決めるべきことは何か

実装に入る前に3つ決めておく必要があります。参照させるデータの範囲、自律実行させる範囲、そして成果をどう測るか。この3つは実装のどのルートを選んでも必要になり、かつ決めるのに時間がかかります。

3つのうち最も見落とされるのは成果の測り方です。着手後には取り返せないためです。対象業務の件数と1件あたりの所要時間を2週間分記録するだけで足りますが、この工程を工程表に置いていないと、完成後に「速くなった気がする」しか言えなくなります。

ワークフローで足りる場合はどう判別するか

作らない判断も、作り方の一部です。Anthropicは技術記事で、LLMとツールが「あらかじめ定義されたコードパス」を通じて連携するシステムをワークフロー、LLMが「自らのプロセスとツール利用を動的に決定する」システムをエージェントと定義し分けたうえで、最もシンプルな解を探し必要になったときだけ複雑性を上げるべきだと述べています。エージェントは高コストと誤りの連鎖リスクを伴うためです（参考：Anthropic「Building Effective AI Agents」2024年12月19日）。

この判別は、外部に発注する場合にも効きます。Gartnerは既存のAIアシスタント・RPA・チャットボットを実質的なエージェント機能を伴わないまま再ブランドする動きを「agent washing」と呼び、数千あるエージェント型AIベンダーのうち実体があるのは約130社にすぎないと推定しています。作るか買うかの判断の前に、提案されているものがどちらなのかを確認することになります。

判別の基準は、OpenAIの実務ガイドが挙げる3条件が使えます。複雑な意思決定を含むか、ルールセットが膨大で維持が困難になっているか、非構造データへの依存が強いか。同ガイドは、これらに当てはまらない場合は決定論的な解決策で足りると述べています。定型の転記や条件が明確な承認は、ワークフローで作るほうが安価で確実です。

作り方には何ルートあるのか？

実装のルートは3つに整理できます。どれが優れているという話ではなく、対象業務の性質と自社の体制で決まります。

3つのルートはどう違うのか

違いは、作る対象の範囲と、あとから変更できる自由度のトレードオフです。ノーコードは着手が早い代わりに、できることの上限が提供側の設計に縛られます。自社開発は上限がない代わりに、運用と改訂を自社で抱えます。

③の具体例としては、問い合わせの一次対応を担う顧客対応エージェント、企業調査と初回接触の起案を担う案件創出エージェント、CRMデータの整備を担うデータエージェントがあります。

実務では3つを併用します。定型業務は③、自社の業務フローに合わせる部分は①、競争力の源泉になる領域は②という配分です。最初から②に入る企画は、対象業務の選定を誤っている場合があります。

どのルートを選ぶかは何で決まるのか

判断軸は2つに絞れます。対象業務が自社固有かどうか、そして参照先データがどこにあるか。この2軸で分けると、ルートはほぼ一意に決まります。

対象業務が多くの企業で共通する類型（問い合わせの一次対応、リードの調査、データの重複整理）であれば③から検討します。自社の業務フローに合わせる必要があるが判断のロジック自体は複雑でない場合は①。代理店構造や独自の与信ルールのように、判断のロジックが自社固有で競争力に直結する場合が②です。

参照先データがCRMや業務システムの中にある場合、そのシステム上で作る①が有利になります。データを外に出さずに済むためです。逆に参照先が複数システムに分散していて統合が必要な場合は、統合の設計が先の工程になります。この整備の考え方はAIが動かない本当の理由はデータにあるで扱っています。

先進企業はどう使い分けているか

総務省の令和8年版情報通信白書には、この使い分けの実例が記述されています。イオングループでは、幅広い業態で蓄積された膨大な顧客データの活用に向け、複数のAIエージェントが連携するマルチエージェントシステムを内製により開発中であるとされています。ダイキン工業では、空調機の専門知識に関する生成AIの精度向上を目指し独自のLLM開発に着手しているとされています。同白書は、いずれも自社で独自のノウハウやデータを持ち競争力の源泉となる領域において更なる価値創出を図るための取組だとしています（参考：総務省「令和8年版 情報通信白書｜AI導入・活用を効果的に進めていくために重要となる要素」）。

ダイキン工業の事例はさらに具体的です。同白書によると、現場を担ってきた熟練のエンジニアが将来的に減少することが見込まれているところ、ウェアラブル端末で撮影した作業映像を基に空調機の点検・修理作業の抜け漏れを自動チェックし、その結果をスマートフォンに通知する「熟練工AIエージェント」を自社開発したとされています。一方、設備の異常が故障かどうかを判定して原因や対策も提示する「故障診断AIエージェント」は日立製作所と共同で開発・導入しており、蓄積してきた設備図面や過去の保全記録などをグラフ構造で表現するデータモデル（ナレッジグラフ）として取り込んでいるとされています（参考：総務省「令和8年版 情報通信白書｜製造・生産」／ダイキン工業・日立製作所「ダイキンと日立が協創、工場の設備故障診断を支援するAIエージェントの実用化に向けた試験運用を開始」2025年4月22日）。

この判断の背景には、基盤への投資が成果を分けるという構造があります。Gartnerは2026年4月の発表で、AI施策が成功していると回答した組織は、データ品質・ガバナンス・AI-Ready人材・チェンジマネジメントといった基盤領域に、成果が乏しい組織と比べて売上比で最大4倍を投資していたと報告しています。またAI-Readyなデータ・アナリティクス能力の成熟度が最も高い組織は最大65%高いビジネス成果を達成しているとされています（参考：Gartner「Organizations with Successful AI Initiatives Invest Up to Four Times More in Data and Analytics Foundations」2026年4月16日）。同白書も国立情報学研究所の佐藤一郎教授の指摘として、AI導入に成功するための最初のステップとしてAIに対応するデータがあるかどうか、つまり「AI-Ready」化ができているかどうかという点があり、特にAIエージェントの活用に向けてはデータの精度と鮮度がより重要となることを紹介しています。

この2社に共通するのは、自社にしかないデータがある領域だけを内製に回している点です。汎用の領域まで内製すると、人材と運用のコストが対象範囲に比例して増えます。

ルート①：ノーコードで作る場合の手順はどうなるか？

最も着手が早いルートです。参照先がすでにそのシステムにある場合、データ連携の工程が要らないため、設計から検証までを短期間で回せます。

CRM上で作る場合の流れはどうなるか

HubSpotの場合、Agent BuilderはProfessional版・Enterprise版に含まれ、自然言語でカスタムエージェントを構築できます。既製のエージェントとしてCustomer agent・Prospecting agent・Data agent・Breeze Assistantが提供されています（参考：HubSpot「Easily Build Custom AI Agents｜Agent Builder」）。

作る順序は、参照範囲の指定、指示の記述、実行できるアクションの選択、テスト、という流れです。このうち時間がかかるのは指示の記述ではなく参照範囲の指定です。どのオブジェクトのどのプロパティを見せるか、部門や職階でどう絞るかを決める必要があり、これは業務部門と情報システム部門の合意事項になります。具体的な操作手順はAgent Builderの使い方｜自然言語でカスタムAIエージェントを作る手順で扱っています。

何を指示として書くのか

指示に書くべき内容は3種類に分かれます。何をするか、何をしないか、迷ったらどうするか。3つ目が抜けている指示は、想定外の入力が来たときに不適切な回答を返します。

OpenAIの実務ガイドは、複数の用途ごとに個別のプロンプトを維持するのではなく、ポリシー変数を受け取る柔軟な基本プロンプトを1つ使う方法を挙げています。新しい用途が出たときにワークフロー全体を書き直すのではなく、変数を更新すればよくなるという整理です。部門ごとに似たエージェントを増やす計画がある場合、この方式にしておくと保守が軽くなります。

どこでコストが発生するのか

ノーコードのルートでは、構築工数よりランニングが予算の主要因になります。HubSpotの場合、2026年7月23日以降すべてのエージェントがHubSpotクレジットを消費する仕組みになり、カスタムエージェントの消費はエージェントが実行する昇格されたアクション（promoted action）の完了ごとに発生します。消費量はエージェントの複雑性によって変動し、公式ドキュメントには取引喪失エージェントのテスト実行で推定208クレジットという例が示されています（参考：HubSpot「Review estimated credit costs when using agents」最終更新2026年8月6日）。

クレジットの単価と失効条件も公開されています。オーバーレートは1クレジットあたり0.010ドルで10クレジット単位の請求、未使用のクレジットは各利用期間の終了時に失効して翌月に繰り越されません（参考：HubSpot「Understand HubSpot Credits and billing」最終更新2026年7月29日／HubSpot「HubSpot Credits」）。既製エージェントは成果単位で、2026年4月14日以降Customer Agentは解決した会話1件あたり50クレジット（0.50ドル）、Prospecting Agentは接触対象として提案されたリード1件あたり100クレジット（1.00ドル）です（参考：HubSpot「HubSpot's Customer Agent and Prospecting Agent: Now you pay when the task is complete」2026年4月13日）。

試作の段階でテスト実行の推定消費を確認しておくと、本番の月間件数を掛けて年間のランニングが出せます。この数字がないと稟議が作れないため、試作の目的の一つはコストの実測になります。エディションごとに毎月付与されるクレジット数は製品・サービスカタログ側に記載されています（参考：HubSpot「Product & Services Catalog」）。

ルート②：フレームワークで自社開発する場合は何を決めるか？

自社固有の判断を実装するルートです。自由度が高い代わりに、構成の選択を誤ると保守が困難になります。

単一エージェントから始める理由は何か

OpenAIの実務ガイドは、オーケストレーションのパターンを単一エージェント型とマルチエージェント型に大別し、まず単一エージェントの能力を最大化することを推奨しています。エージェントを増やせば概念の分離は直感的になるものの、複雑性とオーバーヘッドが増えるためです。同ガイドは、多くの複雑なワークフローでも、ツールを備えた単一エージェントで十分な場合が多いとしています。

単一エージェントの実装では、実行を繰り返す「run」の考え方が中心になります。同ガイドは、終了条件に達するまでエージェントを動かすループとして実装されることが一般的だとし、終了条件の例としてツール呼び出し、特定の構造化出力、エラー、最大ターン数の到達を挙げています。最大ターン数を設定していない実装は、想定外の入力で止まらなくなります。

マルチエージェントに分割する判断はいつか

分割の目安も具体的に示されています。プロンプトに条件分岐が多く積み上がってテンプレートの拡張が難しくなった場合、そしてツールが増えすぎた場合です。ただし同ガイドはツールの問題を数の問題としては扱っていません。明確に定義された15個以上のツールを問題なく扱えている実装もある一方で、役割が重複した10個未満のツールで苦戦する実装もあると述べています。重要なのは数ではなく重複の有無です。

分割する場合の型は2つです。中央の「マネージャー」エージェントが専門エージェントをツール呼び出しとして統率するマネージャー型（agents as tools）と、複数のエージェントが対等な関係で専門性に応じてタスクを受け渡す分散型（agents handing off to agents）です。同ガイドはマルチエージェント構成をグラフとして表現し、マネージャー型では辺がツール呼び出しを、分散型では辺が実行権の受け渡しを表すと説明しています。

選定の実務的な基準は、運用時に障害を追跡できるかどうかです。監視体制が薄い段階ではマネージャー型のほうが運用しやすくなります。

主要なフレームワークは何があるか

公開されている主要なものとして、OpenAIのAgents SDK（参考：OpenAI「Agents」開発者ドキュメント）とGoogleのAgent Development Kit（参考：Google「Agent Development Kit documentation」）があります。ローコードで構築する選択肢としてはMicrosoft Copilot Studioがあり、エージェントとワークフローを別の構成要素として提供し、両者を組み合わせて業務プロセス全体を自動化できるとしています（参考：Microsoft「Copilot Studio overview」）。CRM基盤側の選択肢としてはSalesforceのAgentforceもあります（参考：Salesforce「Agentforce: The AI Agent Platform」）。

選定で確認すべき点は、後からマルチエージェント構成に拡張できるか、そして既存システムへの接続方式が標準化されているかの2点です。基盤ごとの違いはHubSpot Agent Hub vs Salesforce Agentforce｜基盤としての違いで扱っています。

既存システムとつなぐ設計はどうするか？

どのルートを選んでも、接続先の設計が能力を決めます。エージェントは接続先を通じて情報を得て、接続先を通じて行動するためです。

ツールはどう定義するのか

OpenAIの実務ガイドは、各ツールに標準化された定義を持たせることで、ツールとエージェントの間に柔軟な多対多の関係を作れるとしています。十分に文書化され、テストされ、再利用可能なツールは発見性を高め、バージョン管理を簡素化するという整理です。

実務では、1つの業務システムに対して複数の粒度のツールを用意するかどうかが分岐点になります。粒度を細かくすると組み合わせの自由度は上がりますが、役割が重複しやすくなります。前述のとおり、苦戦の原因は数ではなく重複です。同じ操作を2つのツールで表現していないかを、定義の段階で確認します。

MCPは何を解決するのか

接続の標準化という論点では、MCP（Model Context Protocol）が実務に入ってきています。AIアプリケーションを外部システムに接続するためのオープンソース標準で、ローカルファイルやデータベースといったデータソース、検索エンジンや計算機といったツール、専門的なプロンプトといったワークフローへの接続を標準化します。公式ドキュメントはこれを、電子機器を接続するUSB-Cポートの標準化になぞらえて説明しています（参考：Model Context Protocol「What is the Model Context Protocol (MCP)?」）。

効いてくるのは、接続先が増えたときの保守コストです。接続ごとに個別実装を積み上げる構成では、システムを1つ増やすたびに実装と検証が発生します。標準化されたインターフェースを介する構成では、この増分が抑えられます。HubSpotとの具体的な組み合わせはAgent Hub×MCP連携でできること｜Claude Codeとの組み合わせ設計で扱っています。

レガシーシステムにAPIがない場合はどうするか

OpenAIの実務ガイドは、APIを持たないレガシーシステムについて、エージェントがコンピュータ操作モデルを用いてウェブやアプリケーションのUIを通じて直接そのシステムを操作できると述べています。人間が操作するのと同じ方法です。

ただしこの方式は、UIの変更で壊れるという性質を持ちます。画面の構成が変わると動作しなくなるため、変更頻度の高い画面には向きません。実務上は、当面の回避策として使い、並行してAPI化やデータ連携を進める順序が現実的です。

作った後に必要な設計は何か？

ここが「作り方」の記事で最も省略される部分です。しかし本番運用に入るかどうかは、この設計の有無で決まります。

ガードレールは何種類必要か

OpenAIの実務ガイドは、ガードレールを6種類に整理しています。この一覧は、社内規程やチェックリストにそのまま転記できます。

6つのうち設計順序を決めるのに使えるのはTool safeguardsです。評価軸は、読み取り専用か書き込みを伴うか、巻き戻しが可能か、必要な権限、金銭的影響の4つです。この4軸で対象業務を並べると、着手順が自動的に決まります。読み取り専用で巻き戻し可能な業務から作るのが定石です。

人に戻す条件はどう決めるか

同ガイドは、人の介入を発動させるべき主要なトリガーを2つ挙げています。エージェントの再試行や実行回数の上限を超えた場合、そして機微・不可逆・影響の大きいアクションを実行する場合です。後者の例として、注文のキャンセル、大口の返金承認、支払いの実行が挙げられています。

同ガイドは人の介入を、展開の初期に特に重要な仕組みとして位置づけています。失敗を特定し、エッジケースを洗い出し、堅牢な評価サイクルを確立する助けになるという整理です。つまり人に戻す設計は、品質を下げないための妥協ではなく、改善のための情報源として機能します。

総務省の白書に記述された中外製薬の考え方も同じ方向です。同社はビジネスプロセスの変革においては個人作業の効率化とは異なり、人間とAIの役割分担について十分に検討した上でガバナンスに基づきAIを活用するべきであると考え、AIに行わせた方が良いプロセスと人間が責任を取らなければならない箇所を見極めた上で、人間の判断や確認を適切に介在させる「ヒューマン・イン・ザ・ループ」を重視してビジネスプロセスの再設計に取り組むことが必要であるとしています（参考：総務省「令和8年版 情報通信白書｜中外製薬の事例」）。

評価と改訂は誰が回すか

作った後の運用で必要になるのは、評価の仕組みと改訂の担当です。OpenAIの実務ガイドは、モデル選定において最初に評価（evals）を設定して性能の基準を作ることを推奨しています。基準がないと、モデルを差し替えたときに良くなったのか悪くなったのかが判断できません。

担当については、白書のヒアリング結果が参考になります。同白書によると、AI活用先進企業では事業部門の現場のニーズを検討の起点としつつ、DX推進部門が具体的なアイデアの創出、技術的アドバイスやセキュリティ対策、効果測定、AIスキル等の学習や知見共有を受けられる機会の設定といった伴走支援を担当していたとされています。作った人が改訂も担う体制では、担当者の異動で止まります。失敗要因の詳細はAgent Hub導入で失敗する組織の共通点｜CRMデータ品質と運用ルール設計で扱っています。

準拠すべき枠組みとしては、総務省・経済産業省のAI事業者ガイドライン（第1.1版、2025年3月28日）があります。同ガイドラインはAIの事業活動を担う主体を「AI開発者」「AI提供者」「AI利用者」の3つに大別して整理しており、自社で作って自社で使う場合は複数の立場を兼ねることになります（参考：総務省・経済産業省「AI事業者ガイドライン（第1.1版）」2025年3月28日／経済産業省「AI事業者ガイドライン検討会」）。プロンプトインジェクション等を含む脅威の全体像はIPAの資料で確認できます（参考：IPA「情報セキュリティ10大脅威 2026」）。

あわせて、生成AIの技術的な特性も評価設計に織り込む必要があります。同白書は、生成AIには事実とは異なる情報を出力してしまうハルシネーション、ユーザーに過剰に同調してしまうシカファンシーといった現象のほか、偏見やバイアスにつながる出力リスクも指摘されていると記述しています。これらは1回のテストでは検出しにくいため、継続的な評価の対象になります。

3つのルートのメリット・デメリットを公正に比較するとどうなるか

選定の材料として、3ルートを同じ軸で並べます。自社の状況をこの表に当てはめると、どこで詰まるかが事前に見えます。

この表の使い方としては、対象業務を1つ決めてから3列を読むことをおすすめします。業務を決めずに列を比べると、自由度の高い②が魅力的に見えますが、②を選ぶと保守の負担の行がそのまま自社に乗ります。Gartnerは2025年6月の発表で、エージェント型AIプロジェクトの40%以上が2027年末までに中止されると予測し、理由としてコストの増大、ビジネス価値の不明確さ、不十分なリスク管理を挙げています（参考：Gartner「Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027」2025年6月25日）。

よくある質問（FAQ）

プログラミングができなくてもAIエージェントは作れますか？

ルート①と③は作れます。HubSpotのAgent Builderは自然言語で構築でき、Professional版・Enterprise版に含まれます。ただし参照範囲の指定と権限設計は業務部門と情報システム部門の合意事項であり、技術知識より社内の調整能力が求められます。ルート②は開発の体制が必要です。

まず何から作り始めればよいですか？

読み取り専用で、巻き戻しが効き、権限が閉じていて、金銭的影響がない業務から作ってください。OpenAIの実務ガイドが挙げるTool safeguardsの4軸で最も安全な側です。社内資料の要約や検索の補助が典型です。ここで運用の型を作ってから、書き込みを伴う業務に進みます。

最初からマルチエージェント構成にすべきですか？

推奨しません。OpenAIの実務ガイドは、まず単一エージェントの能力を最大化することを推奨しており、多くの場合ツールを備えた単一エージェントで十分だとしています。分割の目安は、プロンプトの条件分岐が積み上がった場合とツールの役割が重複してきた場合です。この症状が出てから分割します。

ノーコードで作ったものを本番に上げられますか？

権限設計と失敗時の検知が本番条件になっていれば上げられます。試作段階で管理者権限のまま動かしていた場合、本番では部門・職階ごとの権限が必要になります。あわせて、想定外の出力を検知して記録する仕組みと、人に戻す条件の定義が必要です。この3点を試作の段階で本番条件に寄せておくと、そのまま移行できます。

作るコストと使うコストは、どちらが大きくなりますか？

対象業務の件数によります。ノーコードのルートでは構築工数が小さいため、月間件数が多い業務ではランニングが主要因になります。HubSpotの場合、クレジットのオーバーレートは1クレジットあたり0.010ドルで、Customer Agentは解決した会話1件あたり50クレジットです。月間件数に単価を掛けて年間で見ると、どちらが大きいか判断できます。

APIがない社内システムとはつなげませんか？

OpenAIの実務ガイドは、APIを持たないレガシーシステムについて、コンピュータ操作モデルを用いて人間と同じようにUIを通じて操作できると述べています。ただしUIの変更で壊れるため、変更頻度の高い画面には向きません。当面の回避策として使いつつ、API化やデータ連携を並行して進める形が現実的です。

作ったエージェントの品質はどう測ればよいですか？

OpenAIの実務ガイドは、モデル選定の最初に評価を設定して性能の基準を作ることを推奨しています。業務側の指標としては、正しく処理できた件数の割合、人に戻った件数の割合、そして人に戻った理由の分類を記録します。3つ目があると、次の改訂で何を直すかが決まります。

自社開発した場合、担当者が異動したらどうなりますか？

改訂の担当を作った人と分離しておく必要があります。白書のヒアリング結果では、AI活用先進企業において事業部門の現場のニーズを起点としつつ、DX推進部門が技術的アドバイスや効果測定を含む伴走支援を担当していたとされています。作る人と運用を支える人が分かれている構造です。中外製薬では、DX部門の中に事業部門のニーズと技術のブリッジを担う「ビジネスアーキテクトグループ」を2025年に立ち上げたとされています。

まとめ：ルートを決めてから手を動かす

AIエージェントの作り方は、実装の手順ではなくルートの選択から始まります。対象業務が自社固有かどうか、参照先データがどこにあるか。この2軸でノーコード・自社開発・既製エージェントの設定のどれを選ぶかがほぼ決まります。

そしてどのルートでも、実装の前に3つ決める必要があります。参照させるデータの範囲、自律実行させる範囲、成果の測り方です。3つ目は着手後には取り返せないため、対象業務の件数と所要時間を先に記録しておいてください。

作った後の設計も忘れないでください。ガードレール6種のうちTool safeguardsの4軸（読み取りか書き込みか、巻き戻し可能か、必要な権限、金銭的影響）は着手順を決めるのにそのまま使えます。人に戻す条件は品質の妥協ではなく、改善の情報源として機能します。

株式会社100は、世界上位1%・日本唯一のHubSpot認定エリートパートナーとして、CRMを軸にしたAIエージェントの設計・構築を支援しています。対象業務の棚卸しからルートの選定、参照データの整備、ガードレールの設計、成果単位でのコスト見積までを一つの工程として扱っています。どのルートで作るべきかの判断からご相談いただけます。