AIプロダクト開発の始め方、AIエージェントで足りるか問い評価セットを先に作る

出典: 【週刊AI】「作れる」が当たり前になった今、どんなプロダクトが売れるのか？｜AI業界の大きな潮流を読む

AIで作ることが当たり前になった今、プロダクトの話はどこから始めればいいんでしょうか？動画は、その手前から入ります。前提の確認です。

動画の最初の話題は、前提の確認です。遠藤さんが、AIのモデルは四半期ごとに世代交代していると話します。1年ほど前まではAIでどこまでできるかの検証から始めることが多かったのに、今は精度が上がり、やりたいことに最初から精度が出る形に変わってきた、という説明です。

違いは、処理が成り立つかどうかにも出ています。去年は高くて諦めた処理が、今年は成り立ちます。去年はAIでは難しかったことも、できるようになっている、という話でした。

湯川さんが、できないと諦めずに、最近は1か月に1回ぐらい試して、使えるかどうかを確かめるといい、と話します。

湯川さん（動画 7:33〜）

最近は1ヶ月1回ぐらい試してみて使えるかどうかそしたら使えるポーンと使えるようになってるかもしんないので

遠藤さんは、まずは疑わずに最新モデルでできるかどうかを試すのが、最近のポイントだと続けます。

プロトタイプを作るのも、圧倒的に早くなったそうです。1年前なら大変だったことが、最近は数分でリリースまでできる世界観になってきた、という話です。業務アプリは作れるようになり、お客さんに出せるレベルかは疑問が残るものの、社内で使う物やプロトタイプならすぐできる、という線引きでした。

事前に準備を重ねるより、作って動かして、違ったら捨てて作り直す方が早い、とも話します。

遠藤さん（動画 9:14〜）

とりあえず作って動かしてみてなんか違ったら捨ててもう1回やり直す、作り直すとかアップデートするみたいな方がもう圧倒的に早くなってるなっていう感覚はありますね。

スライドには、非エンジニアの経理・総務の担当者が、自分の業務アプリ（リード管理・営業管理）を内製した例が並びます。エンジニアがいないから作れない、は理由にならなくなりつつある、とあります。裏返すと、動くものを見せるだけでは差がつかない、とも書かれています。

遠藤さんの会社でも、業務のタスクリストを内製していると話します。会議や営業の内容、メール、チームのチャットを、AIが顧客ごとに整理しているそうです。営業管理のソフトも、どこまで要るのか。そんな感覚になる、と続けます。

作るコストが下がった話と、ちゃんと作るにはまだコストがかかる話。いやー、この2本が同じ流れの中に並んでいるのが、この章の芯だと私は見ています！

私は2026年10月12日の朝LIVEで、共演者から、このカードを投稿するサイトはどのくらいかけて作ったのかと聞かれました。答えは、昨日寝る前に作っといてと頼んだ、でした。

朝LIVEに間に合うように、過去のライブで話した内容のアイデアも参考にして、とも頼んでいます。サイトは Claude Code（Opus 5.5）で作っていて、LIVEの時点では、まだ完成していません。

でね、頼むことと、できたと言えることは別物。作る速さが上がるほど、頼んだ後に確かめる場面が、手元に残ります。

動画の中でも、昔の結論を捨てずに、今の手応えを足していく運びが何度も顔を出します。去年ダメだった、で止めずに試し直す姿勢。去年あきらめた処理は、どうでしょう？そのままになっていませんか？

作る速さの話は、確かめる工程の話と並べて聞くと、いちばん使えます！

業務で困りごとが出た時。すぐに専用アプリを作りたくなりますよね？その前に見ておきたい地図が、この章の話です。

遠藤さんが、AI活用を大きく2種類に分けます。ひとつ目は、アプリとして作らずに回す業務運用。ふたつ目は、プロダクトとして外に出す話です。

業務運用では、汎用のエージェントに設定を加え、動き方の設定（ハーネス）をちゃんと作れば、作らずに回ります。社内だけでなく、お客さん向けにシステム開発してきた仕事も、エージェントの設定を回すだけで足りることがある、と話します。

肝になるのは、ここです。エージェントを業務の情報源につなぐこと。クラウドのストレージ、メール、チャット、カレンダーに、どの権限でつなぐか。そこから作った物を誰が見られるか。そこを設定するのがポイント、という話です。

加えて、ルーチンやスキルを使えば、いちいち指示を打たなくても一定程度は自動で回ります。情報源はクラウドのストレージやデータベースに置き、画面の部分は別に作ることもできるそうです。それぞれのユーザーのエージェントが情報源を読みに行く設計なら、やりたいことはかなりできる、と話します。

プロダクトの側は、生成AIを組み込んだサービスを外に出す話です。商品の価値はモデル自体より、独自データ、ノウハウ、プロダクトの信頼性が差別化になる、と遠藤さんは話します。エージェントと設定で間に合う領域はプロダクト化しにくく、その領域が増えているので、どこに価値を出すかが悩ましくなっている、とも続けます。

ここで湯川さんが質問します。会社の規模が大きくなると、誰にどの書類を見せていいか、誰が何に入れるかの設定が大変になるのではないか、という問いです。

湯川さん（動画 16:24〜）

僕個人だから全然ね、あの全て自分が見れたらいいと思うんでやってるんですけど、え、会社規模なっていくと大変だなと思うので

権限を管理するツールを先に入れるのか、とも聞きます。遠藤さんの答えは、以前に調べた時は全部見積もりは相談で、人が個別に対応する物だと感じた、というものでした。

自社でやっているのは、情報を整理するエージェントと、各自がアクセスするところの切り分けです。

遠藤さん（動画 17:18〜）

その情報を整理するエージェントと各自がアクセスするところっていうのを切り分けて

整理する側には、比較的広い権限を持たせて情報を整理させます。各自のエージェントは、社員1人ひとりの権限設定に結びつけ、その人が見える範囲だけを見に行く形。エージェントを2層にしている、という説明です。

正直、この2種類の線引きが、作る前の最初の質問になっているのが大きいと私は見ています。作らずに回るか。まずそこを問う順番です。

困りごとが出るたびに専用アプリを作る前に、汎用のエージェントに設定を足すだけで回らないかを確かめる順番。これは、手数を減らす見方として筋が通っていると思います！

で、肝の権限設計は、技術の話というより、見せる範囲を人ごとに決める話なんですよね。

2層の形は、整理する側と見る側で権限の広さを分ける設計だと、私は見ます。会社が大きくても小さくても、AIに何を見せるかを先に決めるところから始まるんです！

作る前に、作らずに回るかを問うこと。それが、この地図の入口です！

AIに会議の中身まで読ませたら、次に気になるのは、どこまで動かしてよいのか、ですよね？第3章は、遠藤さんの会社で情報を整理する側の話から始まり、AIが動く範囲の決め方へ進みます。

整理する側の例が続きます。遠藤さんの会社では、全部の会議と営業を録画し、書き起こしから要点を出し、人がレビューしてデータをためています。この土台を、別の流れでさらに分析する、という話でした。

お客さんごとに保存します。起きた出来事をデータとして。プロダクトへの意見もトピックごとにまとめ、いつの会議で誰が言ったかを逆引きできる形で、1つのデータベースに蓄積。資料を作る時に、こういう背景の発言をまとめて、とエージェントに頼むと、発言の索引から合う物を探してまとめてくれる、という説明です。

雑談も出ます。電話の録音はお客さんに嫌がられたのに、録画はあまり嫌がられない、という話が出ます。電話より情報量が多い録画のほうが受け入れられている、その差を面白がって笑う場面です。

ここから運用ルールの話です。整理した情報を各自のエージェントが読みに行く時、AIが動く範囲を、許可・確認・禁止で決めます。

遠藤さん（動画 20:49〜）

ここまでは自分で考えて動いていいですよっていうこととこれに関しては必ず人間の確認を挟んでくださいみたいなところとえっとこれはやらない。

スライドの例はこうです。許可は、下書きの作成、情報収集、社内システムへの追記など。確認は、AIが提案して人がレビューしてから実行する物で、外部への送信や支払いを伴う処理など。禁止は、本番データの上書き、顧客への直接の送信など。禁止は、権限を渡さないことでも守れます。そう話します。

加えて、分からないことは、事実、見立て、要確認のフラグを付けて言わせます。人が承認した物だけを正とする、という決めです。スライドの下帯は、エージェントは失敗する前提で境界線を先に引く、それがそのまま信頼性になる、という趣旨でした。

境界線が、性能ではなく信頼性の話として出てくる所。ここが、第3章の芯だと私は見ます。

AIが賢くなれば、任せられる範囲は広がります。その広がりより、線を引くほうが先。正直、そこに信頼性という言葉を置いたのが、この章で一番大事な所だと思います！

私は2026年10月2日の記事に、OpenAI の Dots の活用事例を約40件読んだ私の結論を書きました。結論は、任せる前に、境界を先に書くこと。

dot には、操作ごとに4つの動きを選べる承認ルールがあります。その記事では、境界と5つの頼み事を1通に書いて、自分の dot に送りました。結果が返るまで、私の場合は8分でした！

私の記事より（OpenAI Dotsの活用事例まとめ。発表3日の約40件を用途別に整理し、私のdotで5つ試した・任せる前に境界を決める。承認ルール4段階に、仕事を振り分けるの節）

dotには、操作ごとに4つの動きを選べる承認ルールがあります。聞かずに実行する、明示的に頼んだ時だけ実行する、実行前に毎回確認する、本人に渡す。

遠藤さんの許可・確認・禁止は3段。私が使った承認ルールは4種類です。段の数は違っても、任せる前に線を引く形は同じ向きだと私は判断します。

実は、ここで大事なのは段の数ではないんです。線を引く場所を、頼む前に決めておくこと。そこが共通していると見ています。

失敗する前提で境界を先に書く、というのは、事故を減らすための話にとどまりません。人が最後に見る範囲を決める話なんですよね。

全部をAIに任せるのでも、全部を人が見るのでもありません。間に確認の段を置くからこそ、人の目を使う所が絞れると私は考えます。

禁止を権限で守る話は、言葉で止めるより、そもそも届かない所に置くやり方です。人が見張る手間が減る向きだと私は考えます。

境界を書かないまま任せたら、どうなるでしょう？人はどこを見ればいいんでしょう？だから、先に書く順番なんです！

私なら、AIに任せる前に、許可・確認・禁止の3段で頼む仕事を振り分けてから、頼みます。

社内でエージェントを回せば、やりたいことの多くに手が届く時代。そんな中で、外に出す商品は何で選ばれるんでしょう？第4章は、湯川さんのこの問いから、商品価値の中身へ進みます。

湯川さんの問いから始まります。ここまでの話なら、やりたいことは社内でかなりできます。それなら、プロダクトとして出す時は？何が商品価値になるのでしょう？社内で回せば何でもできて、他のプロダクトを買う必要がなくなりかねない、という問いです。

遠藤さんの答えは、企画を考える時、最初に、この企画は汎用エージェントと設定で再現できないかを問うことです。スライドは、内部利用と、外に出すプロダクトの2枠。

内部利用は、汎用エージェント、クラウドのストレージ、ルーチン、スキルで足りることが多く、作るのは設定と承認の流れです。外に出すプロダクトには、毎回頼まなくても業務の流れの中で動く画面の設計が要り、独自のデータ・ノウハウ・信頼性を組み込んで届ける必要がある、と話します。

汎用エージェントを全社員に入れるのが大変な会社なら、業務に合った専用の画面があるプロダクトを手頃な形で出すのは選択肢になる、とも話します。

続いて信頼性の話。AIが答えを出してきた時に、それをどれだけ信じるか、がポイントになります。

遠藤さん（動画 24:08〜）

特に信頼性みたいなところはAIが答えを出してきました。それをどれだけ信じるかみたいな話になってくると思うんで

信頼がついていないと、担当者の判断が重くなります。プロの誰々や、どこかの大学の教授が監修している、と言えると信じやすくなる、という話でした。

ここで湯川さんが、自分の記事の例を挙げます。記事はAIに書いてもらっていて、AI新聞として出す責任は自分が持っている、という点です。

湯川さん（動画 25:00〜）

やっぱりAI新聞ていうのは僕が責任を持って出してますというところがあのポイントかなみたいな。

AIは反省っぽいことは言っても、痛みを感じません。人間は、信用をなくして仕事がなくなれば、食べていけなくなる痛みを感じます。人が裏に立って責任を持つことが、1つの価値になる、と湯川さんは続けます。

税理士の例も出ます。税務のソフトでもできてしまうけれど、湯川さんは税理士さんにお願いしています。違いは、税務署から連絡が来た時に、自分が対応するのか、税理士さんが対応してくれるのか、の所。その安心感が頼む理由、という話です。

湯川さん（動画 25:51〜）

何かあった時に税務所から連絡来た時に、あの僕は対応しないといけないのか、税理さんが対応してくれるのかの違いみたいな安心感

遠藤さんは、商品価値を整理します。独自データは、自社にしかない蓄積です。お客さんの利益、現場の記録、業界特有であまりネットに出ていない情報。汎用のAIにない物を埋める話です。形式知です。ノウハウは、現場の判断基準や何を良しとするかで、暗黙知寄りの話でした。

暗黙知を形式知にできるのか、という湯川さんの問いに、遠藤さんは、できるとは言い切れないと断ってから答えます。会議の書き起こしやチャットのやり取りを入れて、基準を言語化してみる方法。それを担当者やマネージャーが改めてチェックして直す、というやり方です。

湯川さんは、アメリカのベンチャーキャピタリストの意見も紹介します。人間の中にある暗黙知を形式知にするだけでは足りず、人間が持っていない暗黙知のほうへ行く必要がある、という意見。シミュレーションや実験を繰り返して取りに行く考え方、と話します。

画面の設計は、今はとてもまねされやすい、と遠藤さんが話します。独自にして売るのは難しいだろう。そういう見方。商品価値としては、既存の顧客基盤も大きい、と加えます。

湯川さんも、顧客基盤は信頼の一部だと話します。新しく作って新しいお客さんに売るより、既存のお客さんにAIの機能を足してつなぎとめるほうが楽だと思う、という意見です。

機能の多さより、独自データ・ノウハウ・信頼性。第4章で商品価値が置かれた場所は、ここでした。

いやー、税理士さんの例を聞くと、ソフトでできることと、何かあった時に誰が出てくるかは、別の話なんですよね！

私は、窓口を任せたあとの忙しさは、速さより、終点まで引き受ける一人が誰かで決まる、と見ています（2026年10月15日の記事）。

一つのボールは一人が全部持ち、複数人の共同責任にはしません。所有者は一人。

窓口を任せるのも、商品を外に出すのも、最後に誰が持つかの話。私はそこを、速さの話と分けて考えています。

私の記事より（Claude Code コーディネーターに任せても忙しいなら、終点を持つ人を決める・Claude Codeのプロジェクトは、チャットのプロジェクトと何が違うのかの節）

窓口を任せたあとの忙しさは、速さより、終点まで引き受ける一人が誰かで決まる、と私は見ています。速さは、その次です。

湯川さんの、AI新聞は自分が責任を持って出している、という話。私の、責任の持ち主を一人にする見方とは、責任を人が持つという点で並べて考えられると私は思います。

AIは痛みを感じない、という湯川さんの言葉も、ここにつながります。痛みを負うのが人、という置き方。

でね、画面の設計はまねされやすい。外に出す商品に、何が残るでしょう？

私は、独自データ、ノウハウ、そして引き受ける人の信頼だと見ます。この3点のうち、最後の信頼は、画面のようには写し取れません！

独自データやノウハウは、書き起こしやチャットから言葉にしていく物です。一方で信頼は、出した物に誰が名前を出しているかで決まる所があると私は考えます。監修者の名前が出ると信じやすい、という遠藤さんの話も、同じ所に立つ話です。

実は、社内で回すか外に出すかの分かれ目も、ここに出てくるんですよね。社内なら、引き受けるのは自分たち。外に出すなら、引き受ける人ごと届けます。

機能を足すほど、まねされる物も増えます。だから、誰が責任を持つかが先。そこが商品の芯になると私は見ます！

商品の価値は、機能より、最後に誰が引き受けるかに出ます。

AIの出力は、同じ頼み方でも毎回ぶれます。では、本開発に進む前に、何をそろえておけばいいのでしょう？この章は、PoCの回し方の話です。

遠藤さんは、ここからAIに関するPoC（実証実験）の話に移ります。昔はご自身もたくさん回していた、と話します。PoCが要る理由は、AIの出力がぶれること、そして仕様に書けるとは限らないことです。用意したデータとケースで、どこまで精度が出るかを確かめる場、という位置づけでした。

確かめる項目は、実現性、AIを使うことが課題に合っているか、リスクです。リスクは、小さく試すこと。問題点を先に見つける意味。ほかに、投資対効果とAPIの利用量、社内の理解、投資を集める上での説得材料が並びます。

話の中で、今年は変わってきた、とも触れます。一昔前はできないことが多く、本当にできるかの検証が中心でした。今は最初から精度が出るので、どういう時に思い通りに動かないかを炙り出す使い方。あわせて、どのレベルのモデルなら足りるかを見ておくと、投資対効果が見込める、という話です。

回し方は、スライドに順番で並んでいます。評価セット（理想の入力と理想の出力を20〜30件）の作成。プロトタイプでの一括実行。判定用のAIによる達成率の数値化。外れたケースを直しての再実行。スライドの題は、評価セットが、AI出力の仕様書になる、です。

評価セットがあれば、新しいモデルが出た時も同じケースで回し、乗り換えてよいかを比べやすい、と遠藤さんは続けます。ここで湯川さんが、評価セットが会社の一番の資産だ、という意見を聞いたことがある、と話します。

湯川さん（動画 35:52〜）

評価セットを作れるとなんかもうあとはAIはその評価セットに向かってどんどん賢くなっていくので

一方で、難しさの話も出ます。レポートを作る、といった仕事は、仕上がりの良し悪しの判断が難しく、結局は人が見ないと分からないそうです。どこまで自動化できるかは難しいけれど、一定程度あるとよい、という話でした。

最近は爆速で作れるので、最初は画面をまったく作らず、モデルだけでどのくらいできるかを確かめます。作る段階では、独自データとノウハウを、AIに渡せる形に整理します。ここは人手がかかる所。エージェントが見えるフォルダに、索引と、どういう時に何を見るかを書いた文書を置くと、精度が変わる、という話です。

PoCで詰まるパターンも、3点並びます。1点目は、評価を十分にしないまま、なんとなく動くので本開発に進み、意外と思い通りにいかず破綻する形。2点目は、汎用エージェントで足りる所まで作り込み、エージェントやモデルの更新で、足した機能が不要になる形です。例として、PDFを添付できなかった頃に、添付できる形で人気になったサービスが、数か月後にAI本体の対応で使われなくなった話が出ます。

遠藤さん（動画 39:55〜）

今足りないところを作り込んでもすぐ不要になりますよ。

3点目は、AIだけでできるつもりで進めたら、途中で人の確認を挟まないと回らないケースがあった形。結局全部を確認するようにしたら、生産性があまり上がらなかった、ということもたまにある、と話します。

遠藤さん（動画 40:16〜）

AIだけでできるつもりでやったら意外と人が途中で確認しないと、うん、結構うまくいかないケースがあって、結局全部確認するようにしたら

締めくくりに、遠藤さんのまとめが3点映ります。1点目は、まず最新のモデルで、やりたいことができるかを試すこと。2点目は、商品価値は独自データ・ノウハウ・信頼性で、画面の設計も差別化になるものの、まねされやすいリスクがあること。3点目は、評価セットを作り、毎回試しながら進めること。この3点が、エージェントで何かしようとする時の思考の助けになる、という締めでした。

詰まる3点を並べてみると、3点目だけ性質が違うんですよね！

1点目と2点目は、作り方の話。3点目は、確認する人の側の設計の話です。

実は私の所でも、統括役のタスクの配下に20本が溜まったことがあります。その全部を、私が目で見る状態になっていました。

でね、統括全部やめろ、と言って、統括役をやめたんです。

共同の責任にした時点で、最後に見るのは私になります。2026年10月21日の記事に、そう書きました。

私の記事より（AIの出力を確認する負担は、使うAIの窓口を絞り、読む画面を1ページにして、選ぶ判断を減らすと軽くなる・AIの出力を確認する負担は、使うAIの窓口を絞ると軽くなる形。実演はClaudeとOrcaの節）

正直、ここが分かれ目。共同の責任にした時点で、最後に見るのは私になります。全部を一人で見る形に、戻ってしまうんですよね。

動画の3点目は、人の確認範囲を決めずに進めると、結局全部を確認する形に戻る、という話でした。私の記事は、共同の責任にすると最後に見るのは私になる、という話。確認が最後は人に戻ってくる点で、この2本は並べて考えられると見ています。

評価セットや、捨てられる速度は、作り方の工夫です。確認する範囲は、誰が最後に見るかの設計。

作る速さは上がりました。見る側はどうなるでしょう？後者を最初に決めないと、速く作るほど、人の目が詰まっていきます。私はそう見ています！

確認の範囲は、PoCの最後の片付けではなく、最初に決める設計です！

AIのニュースは、多すぎて全部は追えません。では、その中から湯川さんが今週選んだ3本は、何だったのでしょう？最後の章は、気になる発言の紹介です。

動画の後半で、湯川さんは、今週は気になる発言だけを取り上げる、と話します。友人が気になる発言が好きだと言うので、という前置き付き。画面は、紺色の番組スライドに切り替わります。

1本目は、Googleのピチャイ氏の発言です。シリコンバレーでは、Googleは最先端モデルから脱落しつつある、という見方が一部で主流になっている、と紹介されます。理由の説明は、クラウドや検索事業に計算資源を取られ、儲かる方に計算資源が回るから、というもの。

湯川さん（動画 42:42〜）

クラウドの会社としてはGoogleはもちろん強いんだけれども、最先端モデルの会社としてはもうトップ集団から脱落していっている

それに対してピチャイ氏は、最先端モデルの開発を優先していて、計算資源もそちらに回している、と反論しました。

湯川さん（動画 43:12〜）

そんなことないと最先端モデルを開発するのを優先してるんだと。

スライドには、最先端のAIの開発を優先して計算資源を配分しているため、Googleクラウドは今この瞬間も短期的な売上の機会を手放している、という趣旨の引用が映ります。7月の決算でも最先端モデルを最優先と言っていたが、数字ではっきり見えていない、と湯川さんは話します。話しぶりはあまり力強くなかった印象で、力を入れているけれど追いつけていない構造に聞こえた、とも続けます。

2本目は、Wissner-Gross博士の発言です。AIが5,000疾患の治療候補を3年で発見する、という内容。スライドには、OpenAIの次世代モデルが、数論や幾何など幅広い分野で300件を超える成果を、論文草稿として公開した、とあります。数学の次は生物学だ、という博士の見方も紹介されます。

一方で、生物学は複雑で数学のようにはいかない、という意見もあります。治療候補が見つかっても、実験で確かめる必要は残ります。アメリカでは仮想の細胞のための資金が集まっていて、実験の手間が省ければ、治療ができるまでの時間は縮まる、という話です。治験の期間を縮められるかは政治の問題、とも湯川さんは話します。

3本目は、マスク氏の発言です。大きな言語モデルだけでも大きな経済効果が出るが、ロボットが実験を行うようになれば、経済効果はさらに桁が変わる、という趣旨。新素材やエネルギー、薬も、そういう形で出てくるという見方と、価値の基準が変わるのではないかという話も、あわせて紹介されました。

いやー、3本とも話が大きいですね！

ここで押さえておきたいのは、3本とも、他の人の発言を湯川さんが紹介する形だということ。遠藤さんの話とは、別の層の話です。

1本目は、見立てと反論が並ぶ話。2本目は、先の予測。3本目は、価値の基準の話です。

同じ気になる発言でも、確かめられる所と、まだ予測の所が混ざっています。聞き終えた時、どこまでが今の話で、どこからが先の話か、すぐ答えられますか？

だから、発言は発言として読みます。いま確かめられる所と、先の話を分けて置く聞き方を、私は勧めます！

私なら、気になる発言を聞いたら、確かめられる所と先の予測を、2列に分けて持っておきます。

動画は、まず最新モデルで試す話から始まり、AI活用の2種類の地図、許可・確認・禁止の線引き、外に出す商品の価値、評価セットで回すPoCへと進みました。最後は、湯川さんが選んだ気になる発言3本です。

私が持ち帰ったのは3点。作る前に、作らずに回るかを問うこと。任せる前に、境界を先に決めること。評価の例を先に書くこと。

順番にすると、AIエージェントで足りるか問い評価セットを先に作る、という流れです。AIプロダクト開発は、ここから始めるのが一番ぶれないと見ています。

で、私自身の記事にも、任せる前に境界を書いた場面と、最後に見る人を決め直した場面がありました！作る力より、線を引く側の仕事が残ると見ています。

自分が頼みたい作業は、できた時に何を見て合格と言えますか？