AIエージェントの回帰テストとは？｜直すたび壊れる所

「指示文を1行足した翌週に、触っていない業務から苦情が来た」「つなぐ先を1つ差し替えたら、前から動いていた処理が止まった」——AIエージェントを業務に入れた会社からは、この二つが続けて届きます。どちらも、作りが雑だから起きているのではありません。産業技術総合研究所が2025年5月26日に公開した生成AIの品質に関する指針は、同じ入力を繰り返したときに出力の内容が整合していることを「出力一貫性」という品質の項目として立てています。そのうえで、ばらつきを抑える設定を最も強くしても計算は一つに定まらない、と書いています。演算の実行のされ方、記憶の参照の仕方、数値の精度。そこまで下りたところに、ばらつきの源があるためです。この性質を持つ道具を業務に入れると、直したあとの確認が普通のシステムと同じにはなりません。届く指示がその場で組み立てられる仕組みである以上、どこを直しても全体に効いてしまうからです。この記事では、回帰テストとは何か、変更のたびに何をどう確かめるか、そして誰が受け入れの判断をするかを整理します。

場面。指示文を1行足した翌週に、触っていない業務から苦情が来た

具体的な場面から始めます。問い合わせの一次振り分けと、見積書の下書きを、1つのAIエージェントにまとめて任せている会社があるとします。振り分けの精度が思ったより上がらないので、担当が指示文に1行足しました。「判断に迷う場合は、より広い分類を選ぶこと」。振り分けの成績は上がりました。ここまでは、確かに成功です。

翌週、営業部門から連絡が入ります。見積書の下書きから、いつも入っていた但し書きが消えている、という指摘です。担当は見積書の側を一切触っていません。実際に触っていないので、原因の見当がつかない。調べていくと、足した1行が見積書の場面でも毎回読まれていて、但し書きを入れるか迷ったときに「広く書く」側へ寄った結果、細かい条件の記載が落ちていた、という筋道でした。

この場面で本当に問われているのは、技術の話ではありません。誰が気づくか、そして気づいたあとに誰が止めるか、です。作った側は自分の変更を疑いません。成績が上がったからです。使う側は仕組みを知らないので、「最近、下書きの質が落ちた」という感覚でしか言えません。この間を埋める作業が、回帰テストと呼ばれるものです。

回帰テストとは何か。確認テストとの違い

回帰テストは、変更を加えたあとに、変更していない部分が前と同じように動くかを確かめるテストです。情報処理推進機構が公開している応用情報技術者試験のシラバス第7.2版は、検証テストの種類の1つとして「回帰テスト（リグレッションテスト）」を挙げ、同じ語を保守のタスクの用語例にも置いています。作るときではなく、直すときの作業として位置づけられているのがこの語です。日本語では回帰テスト、そのまま音写してリグレッションテストとも呼ばれ、同じものを指します。

対になるのが確認テストです。直した所がちゃんと直ったかを見るのが確認テスト、直していない所が壊れていないかを見るのが回帰テストです。先の場面で言えば、振り分けの成績が上がったかを見るのが確認テストで、見積書の下書きが前と同じかを見るのが回帰テストです。現場では、後者で見つかる不具合を「デグレ」と呼ぶことが多くあります。前より悪くなる、という意味の言葉です。

順番も決まっています。確認テストが通っても、回帰テストが落ちれば、その修正は出せません。ここを逆にすると、「直った、直ったのに苦情が来た」という往復が延々と続きます。先の場面の会社も、振り分けの成績という1つの数字だけを見て出したために、気づくまでに1週間かかりました。直した所の成績が上がったことは、出してよい理由になりません。

導入時の検収は1回、回帰は変更のたび

よく混同されるので、隣にあるものと線を引いておきます。1つ目が導入時の検収です。何を1件と数えるか、合格の線をどこに置くか、誰が立ち会うかを決めて、使えるかどうかの合否を出す関門。当メディアには受け入れの基準そのものを扱った記事があるので、基準の作り方はそちらに譲ります。本稿が扱うのは、その基準を、入れたあと毎回どう使い直すかのほうです。

違いは頻度だけではありません。検収は使えるかを判定します。基準は業務の要求から立ちます。回帰は前と同じかを判定します。基準は前の版の挙動から立ちます。後者は、業務の要求を毎回持ち出さなくても判定できるという利点があります。逆に、検収の基準をそのまま毎回の回帰に使うと重すぎて回りません。検収で使った資料のうち、毎回回せる分量だけを取り出して回帰の束にする、というのが現実的な始め方です。

もう1つ、実務でよく起きる誤解があります。検収で合格を出したのだから、その後の変更にも同じ合格が引き継がれる、という誤解です。引き継がれません。検収は、その時点の版に対する合格です。指示文を直した時点で、それは検収した版とは別のものになっています。契約の上でどう扱うかは会社ごとに違いますが、少なくとも技術の上では、変更のたびに別のものになる、と考えたほうが安全です。

時間とともに落ちる劣化とは、別の話

2つ目の隣が、時間をかけて静かに落ちていく劣化です。扱う中身が変わる、参照している資料が古びる、使う人が増えて聞き方が変わる。こちらが何もしていなくても成績が落ちる現象で、当メディアの別記事が原因と気づき方を扱っています。回帰は、これとは向きが逆です。こちらが直したから落ちる。原因が手元にあります。

見分け方は単純です。落ちた時期が、直した日を境にしているかどうか。直した翌日から落ちているなら回帰、何週間もかけてじわじわ落ちているなら劣化。この判別ができるかどうかは、記録が残っているかで決まります。何を、いつ、誰が変えたか。この3つが台帳にあれば、その場で切り分けられます。無ければ、両方の可能性を同時に追うことになり、調査に数日かかります。

記録が残りにくいのは、変更が小さいときです。指示文の1行、参照する資料の1件、同時に動かす数の設定。どれも数分で直せてしまい、「後で書いておく」と思ったまま忘れられます。実務としては、直す作業と記録を同じ画面で終わらせる形にするのが確実です。台帳を別に置くと、急いでいるときほど書かれません。書く項目は、日付・変えた場所・変えた理由・戻し方の4つで足ります。

なぜ関係のない所が壊れるのか。届く指示は組み立てられている

原因は構造にあります。産業技術総合研究所の指針は、生成AIを使うシステムの主な部品として7つを挙げています。土台になるモデル、指示文とその周辺、外の資料を検索して補う部品、外部の道具や社内システムとつなぐ部品、入口のふるい、出口のふるい、そして人が触る画面です。AIエージェントは、このうち4つ目の役目が重く、目標を受け取って手順を組み立て、必要な道具を順に呼び出しながら進みます。

そして同じ指針は、モデルに届く指示について次のように書いています。「プロンプトは入力であり、一般に出所の異なるいくつかの要素で構成される。通常は、システムプロンプトと、エンドユーザー入力プロンプトの組であるが、場合によっては、外部の連携サービスが発生源になる要素を含むことがある」。つまり、モデルに届く文は、こちらが書いた指示文だけではありません。利用者が打った文、検索が持ってきた資料、道具が返した値が、その場で1つに合成されてから届きます。

ここから、先の場面の答えが出ます。指示文に足した1行は、振り分けのときだけ読まれるのではありません。同じエージェントが動くすべての場面で、毎回届きます。見積書を書く場面でも読まれて、そこでも効いた。それだけの話です。同じ指針は対策として、散文のようにだらだら書くと修正しにくく試験もしにくくなるので、指示文の全体を構造化して段落ごとの役割を明確にせよ、と書いています。回帰テストの手前に、この設計があります。

壊れる原因になる変更は、5種類ある

何を確かめればよいかは、何が変わったかで決まります。実務で起きる変更を分けると、次の5種類に収まります。見るべき列は3つ目ではなく2つ目です。変えるのが自社ではない行は、こちらの都合で日程を決められません。そこが、段取りの重さを分けます。

変えたもの	変えるのは誰か	壊れやすい所	気づく手がかり
指示文（全体にかかる指示の文章）	自社の担当	触っていない業務の書式、但し書き、断り方	変更の日を境に、他の業務の出力を並べて見る
つなぐ道具の仕様（外部の道具や社内システムとの接続）	自社または相手先	道具を選ぶ順番、渡す値の形、失敗したときの戻り方	呼び出しの記録の件数と、失敗した割合
参照する資料（検索して補う側の中身）	業務部門	資料が増えた分だけ、関係のない資料が混じる	出典として引いた文書の内訳が、前月と変わっていないか
モデルの版（提供元による更新）	提供元	断り方、返す長さ、指定した書式の守り方	提供元からの通知と、切り替えた日付の記録
権限と設定（触れる範囲、同時に動かす数、待ち時間の上限）	情報システム部門	途中で止まる、順番が入れ替わる、片方だけ処理される	最後まで終わらなかった件数

1番目と5番目は、自社の変更なのに記録が最も残りにくい組み合わせです。指示文は文書管理の外に置かれがちで、設定は管理画面から直せてしまいます。この2つを変更申告の対象に入れるかどうかが、実務の分かれ目になります。対象に入れていない会社では、調査のたびに「そういえば先週、上限を上げました」という発言が後から出てきます。

4番目については、公的な文書に段取りが書かれています。デジタル庁が2026年6月12日に決定した行政の生成AIの調達・利活用に関する標準ガイドラインは、モデルの大きな更新や大規模な追加学習が行われた場合、「ユーザーへの提供前に」出力が期待する品質を満たしていること、不適切な生成や偏りが出ていないこと、安全対策や必要な費用の変化を確認したうえで提供を開始する、としています。同じ資料の調達の様式には、更新や移行のときに品質と安全性を検証する方法が分かる資料を求める項目も置かれています。

同じ入力で同じ答えが返らないから、一致では判定できない

ここが、普通のシステムの回帰テストと決定的に違う点です。産業技術総合研究所の指針は、出力一貫性という項目を立てて次のように書いています。「同一入力に対して常に同じ出力を生成する確定的な振舞いのコンポーネントは出力一貫性を満たす」。そして大規模言語モデルについては、「その確率的な振舞いに起因して、同一入力に対して、想定を逸脱するような異なる出力が生成されることがある」としています。

ばらつきを抑える設定を最も強くしても、完全には消えません。同じ指針の付録は、その設定で出力層の計算が確定的になるとしたうえで、「言語モデルの推論実行に関わるさまざまな要素から唯一に定まることがない」と書き、演算の実行、記憶の参照の仕方、数値計算の精度を要因として挙げています。つまり、同じものを2回動かして違う答えが返ることは、不具合ではありません。仕様の側にあります。

この性質は、回帰テストの場面で名指しされています。日本のソフトウェアテスト技術者資格の運営組織が公開しているAIのテストを扱う学習要項の日本語訳版は、「同じ前提条件と入力を用いたテストでも、複数の有効な結果が得られる可能性がある」としたうえで、期待する結果の定義が難しくなる場面を4つ挙げています。テストが確認テストに再利用される場合、テストがリグレッションテストに再利用される場合、テストの再現性が重要な場合、テストが自動化されている場合。回帰テストは、難しいと明記されている領域そのものです。

合否は一致ではなく、許容の幅で書く

では、どう判定するか。同じ学習要項は、「テスト担当者は、単に期待されるテスト結果の正確な値を述べるのではなく、テストに合格したかどうかを合理的にチェックできるように、要求されるシステムの動作についてより深い知識を必要とする」と書き、期待する結果には許容範囲が含まれることがある、たとえば実際の結果が最適解の2パーセント以内に収まっているか、という形を例に挙げています。業務で使うときは、完全一致で見る項目と、幅で見る項目と、そもそも入れない項目に3分割するのが実務的です。

• 完全一致で見る。項目名がそろっているか、必須の但し書きが入っているか、宛先が正しいか、禁止している語が入っていないか、数字の桁が合っているか
• 幅で見る。文の長さ、言い回し、並べる順番。上限と下限を数字で決めておき、外れたときだけ人が読む
• 回帰の束に入れない。読みやすいか、丁寧か、といった判定。毎回割れるので、入れると束そのものが信用されなくなる

1番目は、判定を機械に任せられます。文字列として確かめられるからです。実は、業務で本当に困る壊れ方の多くはここに入ります。但し書きが消える、宛先の敬称が変わる、金額の桁が変わる、答えられないときに無理に答える。先の場面で起きたのも1番目の壊れ方でした。まず1番目だけを固めるだけで、回帰テストは半分機能します。

そして、回数です。同じ学習要項は、確率的な性質のために単一の決定的な出力が得られない場合、統計的に有効な結果を得るためにテストを数回実行することがしばしば必要になる、としています。評価の場面では同じ題材を5回から8回回して幅を測る、という進め方が知られていますが、回帰は変更のたびに回すので、そこまでの回数は現実的ではありません。実務では1本につき3回、3回とも落ちたら不合格、1回だけ落ちたらばらつきとして記録に回す、という運用に落ち着くことが多くあります。

前の版を、正解の代わりに使う

回帰テストが評価と違うところが、もう1つあります。正解の一覧を作らなくても始められる、という点です。先の学習要項は、期待する結果を出しにくい場面での手法としてバックツーバックテストを挙げ、「リグレッションテストの場合、そのシステムは前バージョンのシステムを使用できる」と書いています。前の版の出力を、正解の代わりに置くという考え方です。

この置き方をすると、見るものが変わります。評価は「正しいか」を見ますが、回帰は「前と違うか」を見ます。正しさの基準を書き起こす作業を後回しにできるので、着手の障壁がぐっと下がります。実際の手順は、前の版で束を回して結果を保存し、直したあとに同じ束を回して、2つを並べるだけです。そのうえで、出てきた差分を3つに分けます。

1. 前は通って、今回落ちた。これが本命。壊れた候補として、必ず人が中身を見る
2. 前は落ちて、今回通った。直した効果として説明が付くか確かめる。付かないなら、たまたま通っただけの可能性がある
3. 前も今回も落ちた。既知の欠け。放置してよいが、件数が増えていないかだけ見る

1番目が0本でも、安心はできません。壊れていないのではなく、束が壊れた場所を通っていないだけ、ということが起きるからです。判断の目安として、変更した箇所に関係する業務の型が束に入っているかを、毎回1度だけ確かめてください。入っていなければ、1番目が0本という結果には意味がありません。

確かめる題材は、事故から生える

「何本ぶん用意すればよいですか」という質問を、必ず受けます。答えは、最初に本数を決めない、です。決めるのは増やし方の規則のほうです。規則は1つで足ります。一度壊れた所は、必ず1本足す。しかも、直したその日に足す。翌週に回すと、まず足されません。

最初の元手は、導入のときに検収で使った題材です。合否を出した題材は、そのまま回帰の1本目になります。そのうえで、任せている業務の型ごとに1本ずつ置いておきます。型が5つなら5本。ここは薄くて構いません。厚くするのは、実際に事故が起きた型だけです。半年も回すと、事故の分布がそのまま束の分布になります。これが正しい形で、均等に配ると、壊れない所ばかり確かめることになります。

この作り方は、毎週回す評価の束とは別物です。評価の束は、実務で来た依頼、過去に失敗した件、判断が分かれた境目の件から組んで、決めた曜日に当てて成績の推移を見るためのものです。回帰の束は、変更があった日に回して前と比べるためのものです。用途が違うので、1つにまとめると両方回らなくなります。重なる題材があっても構いませんが、回す引き金と見る人は分けてください。

束が太ると、誰も回さなくなる

回帰の束は、放っておくと必ず太ります。壊れるたびに1本足す規則にしているので、当然です。そして太った束は、急ぎの修正のときに飛ばされます。変更のたびに回すものなので、1回あたりにかかる時間が上限になります。人が目で見る部分が30分を超えたあたりから、「今回は軽微だから」という理由で省かれ始めます。

だから、足す規則と一緒に間引きの規則を決めておきます。先の学習要項も同じ問題を書いていて、「リグレッションテストスイートが大きくなりすぎないように、頻繁に最適化を行い、テストケースの選択、優先順位付け、さらには追加を行い、より効果的で効率的なリグレッションテストスイートを作成する必要がある」としています。間引きは減らす作業ではなく、回し続けるための作業です。

• 1年以上一度も落ちていない本を、そのまま残し続ける（半分に減らして残す）
• 扱わなくなった業務の本を外さない（業務が消えたら本も外す）
• 同じ壊れ方を見る本が5本たまっているのに、全部残す（代表の1本に寄せる）
• 外した本を消してしまう（外した理由と日付を残さないと、同じ議論を半年後に繰り返す）

どこまで減らしてよいかは、研究の数字が参考になります。同じ学習要項は、ほとんどの欠陥を検出したまま束の大きさを50パーセント削減できること、欠陥の検出率を大きく落とさずにテストの実行期間を40パーセント削減できることを、研究の結果として紹介しています。半分にしても見つかるものは見つかる、という感覚を持っておくと、間引きの判断が軽くなります。

誰がどう確かめるか。受け入れの体制

ここが本稿の中心です。回帰テストが形だけになる会社には、共通の形があります。直した人が、自分で回して、自分で通していることです。3つの役目は分けてください。直す人、回す人、通す人。兼務が避けられない場合でも、少なくとも通す人だけは別の人にします。

役目	誰が担うか	やること	やらないこと
直す人	作った部門、または委託先	変更の内容と、影響しそうな範囲を申告する。戻し方を用意する	自分の変更の合否を自分で出さない
回す人	情報システム部門	束を回し、差分を3つに分けて表にする。記録を残す	出してよいかの判断をしない。判断材料を作るところまで
通す人	業務部門の責任者	壊れた候補を見て、出すか、直し直すか、止めるかを決める	毎回全部を読まない。壊れた候補だけを見る

通す人を業務部門に置く理由は、はっきりしています。何が正しい出力かを決められるのは、その業務をやっている人だけだからです。先のデジタル庁の標準ガイドラインも、リリース前の入出力の検証について、企画する側だけで作るのが難しい場合は「ユーザーへのヒアリングや開発者等と相談をして作成」する、と書いています。但し書きが1行落ちたことが業務を止める話なのか、次回の修正で足せばよい話なのか。この判断は、仕様書の側からは出てきません。

委託している場合も、通す人は自社に置きます。委託先が束を回して報告を出す形自体は問題ありませんが、報告を受け取るだけの体制にすると、落ちた項目の意味が分からないまま合格が積み上がります。受け取るときに求めるものを先に決めておいてください。回した束の一覧、前の版と今の版のそれぞれの出力そのもの、差分の3分類、そして落ちた本について直したのか見送ったのかの区別。要約だけを受け取る形にすると、要約の誤りに気づけません。

変更を受け入れるまでの5工程

役目が決まったら、順番を固定します。この5工程を紙に1枚で置いておくと、急ぎの修正のときにも省く場所が減ります。所要は、束の大きさにもよりますが、自動で判定できる部分が整っていれば半日から1日に収まります。

飛ばされやすいのは2番目です。急いでいるときほど、「前の記録は残っているから、直してから比べればよい」と考えます。ところが、その記録がいつ取ったものかを確かめないまま比べると、自分の変更のせいなのか、その間に入った提供元の更新のせいなのかが分からなくなります。基準の記録には、取った日付と、そのときのモデルの版を必ず添えてください。

AIに任せてよい工程と、人が決める工程

この作業のうち、機械に寄せられるのは判断材料を作る側です。回す人の仕事の大半がここに入ります。任せてよいのは4つで、いずれも出てきた結果を人がその場で確かめられるものに限られます。

1. 前回との差分の抽出。2つの出力を並べて、変わった箇所を拾わせる。文字の違いだけでなく、項目の欠落、順番の入れ替わり、長さの変化に分類させる
2. 落ちた例の分類。壊れ方でまとめさせる。書式の問題か、内容の問題か、断り方の問題か
3. 確かめる題材の案出し。起きた事故から、似た形の題材を作らせる。採用するかどうかは人が選ぶ
4. 報告の下書き。差分の表から、通す人が読める文にする

束そのものの手入れにも使えます。先の学習要項は、「AIベースのツールは、例えば、過去のテスト結果、関連する不具合、最新の変更点などの情報を分析することで、リグレッションテストスイートの最適化を行うことができる」と書いています。落ちたことのない本、重複している本、最近の変更と関係する本を並べ替えさせるところまでは、機械に寄せてよい作業です。ただし、外す判断は人が残してください。

人が決めるのは3つです。合格の線をどこに置くか。出し直すかどうか。業務を止めるかどうか。この3つを機械に寄せられない理由は、落ちた理由が「基準に合わなかったから」に一本化されてしまうからです。業務を止めるかどうかは、基準の外にあります。月末の締めの直前かどうか、代わりの手段があるかどうか、止めたときに誰が手作業を引き受けるか。こうした事情は、束の中に書かれていません。

• 落ちた本を機械に判定させて、合格と出たものを人が見ない
• 差分の要約だけを読んで判断する。元の2つの出力を残さないと、分類の誤りに気づけない
• 束の間引きを機械に任せきりにして、外した理由を記録に残さない
• 作らせたモデルと同じ系統のモデルに、その出力の合否を判定させる

• 本記事は2026年9月時点の公表資料に基づいています。引用した指針や学習要項は改定されるため、参照時は版と公表日を確かめてください
• 所要時間や回数の目安は、業務の型の数と自動で判定できる項目の割合によって変わります。自社の1回あたりの実測を取ってから決めてください

よくある質問

変更のたびに、束を全部回す必要がありますか

自動で判定できる部分は全部回してください。回す費用は、人の時間ではなく実行の費用だけです。人が目で見る部分は、変更した箇所に関係する型に絞って構いません。ただし、絞る判断をした記録は残してください。絞った範囲の外で壊れたときに、絞り方が甘かったのか、束が足りなかったのかを切り分けられます。

何本くらいから始めればよいですか

導入のときに検収で使った題材に、業務の型ごとに1本を足したところから始めてください。型が5つなら、10本前後になることが多くあります。少なく見えますが、そこから事故のたびに1本ずつ増えます。最初に本数を決めて集めようとすると、たいてい集め終わる前に取り組み自体が止まります。

答えが毎回違うのに、自動で判定できるのですか

できる項目と、できない項目に分かれます。項目名がそろっているか、必須の但し書きが入っているか、禁止語が入っていないか、数字の桁が合っているか。こうした項目は文字列として確かめられるので、答えが違っても判定できます。文章の良し悪しは判定できません。そこは束に入れず、幅で見る項目として上限と下限だけを決めてください。

落ちた項目があるのに、出さざるを得ないときはどうしますか

出して構いませんが、3つを同時に決めてください。いつまでに直すか、それまでの間に人が何を確かめるか、そして誰がその確認の当番になるか。この3つを決めずに出すと、落ちたままの項目が既知の欠けとして固定され、半年後には誰もその意味を説明できなくなります。

指示文の1行の修正も、変更の申告に入れるのですか

入れてください。実務でいちばん壊すのがそこだからです。指示文は文書管理の外に置かれやすく、数分で直せてしまうため、記録が最も残りにくい変更です。申告の内容は、変えた行、変えた理由、戻し方の3つで足ります。様式を重くすると書かれなくなるので、軽くしておくのが要点です。

まとめ

回帰テストは、直した所ではなく、直していない所を確かめる作業です。情報処理推進機構のシラバスが検証テストの種類と保守のタスクの両方にこの語を置いているとおり、作るときではなく直すときの作業として位置づけられています。AIエージェントでこれが特に効くのは、モデルに届く指示が、こちらが書いた文と、利用者の入力と、検索が持ってきた資料と、道具が返した値から、その場で合成されるからです。だから、1行足した指示がすべての場面で毎回届き、触っていない業務のほうが壊れます。

判定は、前回との一致では作れません。産業技術総合研究所の指針が書くとおり、ばらつきを抑える設定を最も強くしても計算は一つに定まらず、資格の学習要項も、期待する結果の定義が難しくなる場面として回帰テストへの再利用を名指ししています。そこで、完全一致で見る項目と幅で見る項目を分け、入れない項目を先に外し、1本につき数回回して判定します。そして前の版の出力を正解の代わりに置けば、正解の一覧を作らなくても始められます。見るのは差分の3分類で、前は通って今回落ちた分だけが本命です。

体制としては、直す人と回す人と通す人を分け、通す人を業務部門に置く。変更のたびに、申告を受け、直す前に基準を取り、差分を3つに分け、壊れた候補だけを上げ、決めたことと足した1本を記録する。差分の抽出、落ちた例の分類、題材の案出し、報告の下書きは機械に寄せてよく、そのときは元の出力を必ず残して、分類の誤りに気づける形にしておく。合格の線と、出し直すか、業務を止めるかは、止まったときに困る人が決める。この分け方をしておけば、直すたびに壊れるという状態は、直すたびに確かめる状態に変わります。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。