Cloudflare Kitesurf徹底解説 — AIエージェント専用ブラウザの仕組みと仕事への影響【2026年8月最新】

Cloudflare Kitesurfとは？AIエージェント専用ブラウザの全体像

発表の概要

Kitesurfは、Cloudflareが2026年8月6日（現地時間）に発表した「AIエージェントのためだけに作られたWebブラウザ」です。Cloudflareは世界中のWebサイトの高速化やセキュリティを裏側で支えるインフラ企業で、日本でも多くの企業サイトやWebサービスが同社のネットワークを経由しています。そのCloudflareが、人間向けのブラウザとはまったく別物の、AI専用ブラウザをゼロから作りました。

要点を先にまとめます。

• 人間向け機能を全部捨てた。タブ、テーマ、拡張機能、ピクセル単位の美しい描画。AIには不要なものを削ぎ落とした
• 圧倒的に軽い。Cloudflareの計測では、従来型ブラウザ（Chromium）と比べてCPU消費は3.1〜3.8分の1、メモリ消費は4.7〜7分の1
• ベータ期間中は無料。同社の「Browser Run」というサービス経由で、開発者なら誰でも試せる（アカウントごとの利用上限あり）
• 将来はオープンソース化予定。公開後は自社環境に専用インスタンスを立てることも視野に入っている

なぜ作られたのか — 「ブラウザは人間向けに作られすぎている」

Cloudflareは発表の中で、既存のブラウザについて「人間のために作られたものであり、AIモデルには不要なオーバーヘッド（余分な負荷）を抱えている」と説明しています。私たちが普段使うChromeのようなブラウザは、画面をなめらかに描画し、動画を再生し、拡張機能を動かすために、大量のメモリとCPUを使います。人間が快適に「見る」ためのコストです。

ところがAIエージェントは画面を「見て楽しむ」わけではありません。エージェントが気にするのはトークン数（AIが読み書きする文章量）、コンテキストウィンドウ（一度に扱える情報量）、処理速度、スケーラビリティ、そしてコストだとCloudflareは整理しています。AIエージェントを1体動かすたびに人間用の重いブラウザを丸ごと1個立ち上げていては、電気代もサーバー代も膨れ上がる。エージェントが何千、何万と動く未来を見据えると、「AI専用の軽いブラウザ」が経済的に必須になる。これがKitesurf誕生の背景です。

人間向けブラウザとの違いを表で整理

ポイントは、KitesurfがChromeの対抗馬ではないことです。人間用ブラウザの市場ではなく、「AIがWebを使うためのインフラ」というまだ誰も取っていない市場を狙っています。私たちが普段使うブラウザが置き換わるわけではなく、その裏側で「AI専用のもう一つのWebの入り口」が生まれつつある、と捉えるのが正確です。

そもそも「AIエージェントがブラウザを使う」とはどういうことか

チャットAIとAIエージェントの違い

ChatGPTのようなチャットAIは「質問したら答えてくれる」道具です。一方AIエージェントは「目的を渡すと、道具を使いながら作業そのものを進めてくれる」存在です。「来週の出張の新幹線とホテルを予約しておいて」「競合3社の料金ページを調べて表にまとめて」といった複数ステップの作業を、自分で段取りして実行するのがエージェントです。

そしてエージェントが実際の作業をするとき、多くの場合に必要になるのがブラウザです。Webサイトを開き、文字を読み取り、フォームに入力し、ボタンを押す。人間にとっての「手と目」にあたる部分を、エージェントはブラウザを通じて手に入れます。

エージェントがブラウザでやること

エージェントによるブラウザ操作は、突飛な未来の話ではありません。すでに開発の現場では、次のような使い方が広がっています。

• 情報収集：指定した複数のWebページを開いて内容を読み取り、要約やスクリーンショットを持ち帰る
• フォーム操作：管理画面や申請フォームに、決まった内容を入力して送信する
• 動作確認：作ったWebサービスの画面をエージェント自身が開いて、正しく表示されるかチェックする
• 定型のWeb作業：毎週のレポートに使うデータを複数のサイトから集めてくる

読者のみなさんの業務に置き換えると、「複数のサイトを見て回って転記する」「同じフォームに繰り返し入力する」「毎朝決まったページを確認する」あたりの作業は、すべてエージェント＋ブラウザの得意領域と重なります。

「RPAと同じでは？」— 似ているようで決定的に違う

RPAを導入した職場にいた方なら、「画面が少し変わっただけで動かなくなった」「直せる人がいなくて放置されている」という光景を見たことがあるかもしれません。あれはRPAが記録した手順をそのまま再生しているだけだからです。レイアウトが変われば壊れるし、想定外が起きれば止まる。直せるのは専用ツールの研修を受けた担当者だけ、というケースが大半でした。

AIエージェントは違います。手順ではなく目的を渡すと、ページの中身を読み、状況を見ながら自分で段取りを組みます。画面が多少変わっても意味を読んで対応しうるし、作る側も日本語で指示できれば入口に立てます。もちろん万能ではなく間違いもしますが、「決められた手順の再生」から「目的を渡して任せる」への変化は、自動化できる仕事の範囲を大きく広げます。Kitesurfのような専用基盤は、この動きを安く・大量に実行するための土台です。

既存ブラウザでは何が問題だったのか

これまで開発者は、エージェントにWeb操作をさせるために「ヘッドレスブラウザ」（画面表示を持たない自動操作用のChromium）を使ってきました。動くことは動くのですが、人間用ブラウザの中身をそのまま使うため、1つ動かすだけでメモリを数百MB単位で消費します。後述するCloudflareの計測では、Chromiumでのスクリーンショット取得に約271MiB（メガバイト強に相当するメモリ単位）を使っていました。

エージェントが1体なら誤差です。しかし「社員全員がエージェントを持つ」「サービスの裏で常時数千のエージェントが動く」規模になると、この重さはそのままサーバー代に跳ね返ります。エージェント時代のボトルネックは、AIの賢さよりも先に「実行コスト」に来る。Kitesurfは、まさにそこを突いたプロダクトです。

Kitesurfの仕組みをやさしく解説 — 4つの部品と設計思想

仕組みの話に入ります。専門用語には補足を付けるので、非エンジニアの方もそのまま読めるはずです。

サーバーレスとV8 isolate — 「借りっぱなしのサーバー」をやめる

Kitesurfの最大の特徴は、Cloudflare Workersというサーバーレス基盤の上で動くことです。サーバーレスとは「サーバーを常時借りて管理する代わりに、処理が必要な瞬間だけ小さな実行環境を借りる」仕組みのこと。そしてWorkersの実行環境はV8 isolate（アイソレート）と呼ばれる、Chromeと同じJavaScriptエンジンが提供する超軽量な「隔離された小部屋」です。

従来のヘッドレスブラウザ運用が「エージェント1体ごとに一軒家（仮想マシンやコンテナ）を建てる」やり方だとすれば、Kitesurfは「巨大マンションの小部屋を、必要な瞬間だけ借りる」やり方です。部屋の立ち上げは一瞬で、使い終わったら即返す。この構造が、後述する劇的なメモリ削減につながっています。

中身はRust製の部品の組み合わせ — ゼロから全部は作っていない

Kitesurfは12週間（最初のコミットは2026年5月）という短期間で発表まで到達していますが、これは既存のオープンソース部品をうまく組み合わせたからです。主な部品は次のとおりです。

• Blitz：モジュール式のレンダリングエンジン（Webページの見た目を組み立てる部品）。ページの描画にはblitz-paintを使用
• Stylo：Firefoxでも使われているCSSエンジン（ページのデザイン指定を解釈する部品）
• Boa：Rust製のJavaScriptエンジン。ページ内のスクリプト実行の一部を担当
• Parley：文字の整形（テキストシェイピング）を担当

いずれもRust（ラスト）という、高速さと安全性で近年人気のプログラミング言語で書かれた部品で、WebAssembly（ブラウザやサーバーレス環境で高速に動く実行形式）に変換されてWorkers上で動きます。報道によれば、プロジェクトの着想元はObscuraというオープンソースのRust製ヘッドレスエンジンで、最初の試作はそのWorkers移植だったとされています。

内部は4つの役割に分かれている

Kitesurfの内部は、役割の異なる4つのコンポーネントで構成されています。下の図解と合わせて見てください。

• Engine Worker（受付役）：外部からの操作命令（CDPというブラウザ自動操作の標準規格）を受け付け、セッション状態を管理する
• PageScript（作業役）：ページごとに専用の隔離環境を立ち上げ、JavaScriptやWebAssemblyを実行する
• PageRenderer（撮影役）：BlitzやStyloを使ってページの見た目（ピクセル）を生成する
• SandboxOutbound（出口の警備役）：外部への通信をすべて一手に引き受け、許可されたものだけ通す唯一のネットワーク出口

セキュリティ設計 — 「すべてのページを疑う」が前提

注目すべきは、Kitesurfが最初からAIエージェント特有のセキュリティリスクを前提に設計されていることです。AIエージェントには、Webページに仕込まれた悪意ある文章がAIへの命令として誤解釈される「プロンプトインジェクション」という、人間相手には存在しなかった攻撃手法があります。

Kitesurfの対策は徹底しています。

• 毎回まっさらな状態で起動。前回の情報を引き継がないため、セッションをまたいだ汚染が起きにくい
• すべてのページロードを「信頼できないもの」として隔離。ページごとに独立した実行環境を割り当てる
• 通信の出口を一本化。SandboxOutboundがCORS（外部通信の許可ルール）やCookieの隔離を強制する
• 失敗しても壊れない。例外が起きたら空白のフレームに縮退するだけで、セッション全体は落とさない

ちなみにCloudflareは技術デモとして、このブラウザ上でゲームの「Doom」を動かしてみせています。遊び心のようでいて、「エージェント用に削ぎ落としても、Webの標準技術はここまで動く」という実力の証明になっています。

Chromium比較で見るKitesurfの実力と現在の限界

公式ベンチマーク — CPUとメモリで圧勝

Cloudflareは、14個のURLを対象にした自社計測で、Kitesurfと従来型のChromiumを比較しています。エージェントの典型作業である「スクリーンショット取得」と「HTML抽出（ページの中身のテキスト構造を取り出す作業）」の結果は次のとおりです。

正直に「遅い部分」も公開されているのが好感の持てるところで、処理の完了までの時間はChromiumの1.7〜1.8倍かかります。Chromiumが持つJITコンパイラ（実行しながらコードを高速化する仕組み）の恩恵が大きい部分で、Cloudflareは画像の描画・変換処理を今後の最適化対象として挙げています。

それでもKitesurfが「勝ち」だと言えるのは、エージェント運用の費用を決めるのはCPUとメモリの消費量だからです。1回の作業が半秒遅くても、同じサーバー資源で数倍のエージェントを同時に動かせるなら、大量実行の世界では圧倒的に安くつきます。人間は0.5秒の遅さにイライラしますが、エージェントは文句を言いません。

互換性 — 21.5万件超のWeb標準テストに合格

「削ぎ落としたブラウザ」と聞くと、まともにページが表示できるのか不安になりますが、KitesurfはWeb標準への準拠度を測る共通テスト（Web Platform Tests）に215,000件以上合格しており、対応テストは週に数百件ペースで増えているとされています。CSS・DOM・HTMLといったエージェント作業に重要な領域を優先してカバーしており、報道ではWikipediaやHacker Newsといった実在サイトのレンダリング実績も紹介されています。

開発者はどう使う？ — 既存ツールがそのまま動く

Kitesurfは、Cloudflareの「Browser Run」というブラウザ自動操作サービスの中で、パラメータを1つ足すだけで使えます。

curl -X POST 'https://api.cloudflare.com/client/v4/accounts/<accountId>/browser-run/screenshot?browser=kitesurf' \
  -H 'Authorization: Bearer <apiToken>' \
  -H 'Content-Type: application/json' \
  -d '{"url": "https://example.com"}' \
  --output "screenshot.png"

上のコマンドは「指定したWebページのスクリーンショットをKitesurfで撮って保存する」という指示です（読み飛ばしてOKです）。重要なのは、ブラウザ自動操作の標準規格であるCDP（Chrome DevTools Protocol）に対応しているため、PuppeteerやPlaywrightといった既存の自動操作ツール、さらにAIエージェントとの接続規格であるMCPクライアントからもほぼそのまま使えるという点です。開発者が乗り換えるハードルを、意図的に極限まで下げています。

現在の限界 — まだ万能ではない

いま得意なのは、ページを開いて内容を取り出す・スクリーンショットを撮る・JavaScriptを含む一般的なページを実行する、といったエージェントの高頻度作業です。一方で、動画の再生、WebGL（3D描画）を使うページ、ボット検証（TLSフィンガープリント）への対応、そして数分単位でログイン状態を保つ必要がある作業は、公式が明言している未対応領域です。

つまり現時点のKitesurfは「何でも屋」ではなく、情報収集・内容抽出・表示確認に特化したファーストバージョンです。ログインが必要な業務システムの操作を任せるような使い方は、これからの進化を待つ段階です。

Kitesurfが私たちの仕事に与える影響

インフラ企業が動いた意味 — 「エージェントの大量実行」は既定路線

Kitesurfのニュースで本当に注目すべきは、技術の細部ではありません。「Webの土台を支える企業が、AIエージェントを大量に動かすためのコスト構造を、本気で作り替え始めた」という事実です。インフラ側がここまで動くのは、AIがWebを使う量が人間のそれに迫っていく未来に賭けているからでしょう。ChatGPTの登場から数年で「AIに文章を書かせる」が当たり前になったあのスピード感で、「AIにWeb作業を任せる」も当たり前になっていく。僕はそう見ています。

変わるのは「ブラウザでやっている定型作業」から

エージェント＋専用ブラウザの組み合わせが安く速くなると、真っ先に影響を受けるのは、人間が今ブラウザでやっている「考えなくてもできるが、時間だけは取られる作業」です。

• 複数のサイト・管理画面を見て回って、数字をExcelに転記する
• 毎週・毎月、同じ形式のレポート用データを集めてくる
• 申請フォームや登録フォームに、決まったパターンの入力を繰り返す
• ニュースサイトや競合サイトを巡回してチェックする

思い当たる作業がある方ほど、この変化は他人事ではありません。ただし、ここで大事なのは「奪われる」と怯えることではなく、「先に仕組みを作る側に回る」ことです。

「AIを使う人」と「AIで作る人」の分かれ目

僕が自社サービスに自動返信の仕組みを作った理由は、コメント対応の返信に毎日1〜2時間奪われていた自分自身の痛みでした。その繰り返し作業を仕組み化した結果、いまは1人で運営しながら、カスタマーサポート対応は1日30分以下に収まっています。ShiftBの受講生にも、28歳・元営業職のAさんのように、自分の業務の痛みから議事録自動化ツールを作った人がいます。エンジニア出身かどうかは関係なく、「自分の繰り返し作業を、自分で仕組みに変えた人」から働き方が変わっていく。これは多くの受講生を見てきた実感です。

同じニュースを見ても、「へえ、すごいな」で終わる人と、「自分のあの作業に使えないか」と考える人がいます。繰り返し作業を手作業のまま頑張り続けるか、仕組みごと消す方法を探すか。新しいAIツールの発表に焦るだけか、自分の道具箱に加えて試すか。この小さな反応の差の積み重ねが、1年後に「AI活用はどこか他人事」のままの人と、「AIのことは○○さんに」と頼られる人を分けます。

たとえば、あなたの1週間はこう変わりうる

架空の例をひとつ。営業企画のKさんは毎週月曜、社内の販売管理画面・広告の管理画面・競合3社の料金ページを順に開き、数字をスプレッドシートに転記して定例会議の資料を作っています。所要時間はおよそ2時間。ミスも起きるし、月曜の朝はこの作業のせいで常に憂鬱です。

もしKさんがエージェントに「毎週月曜の朝、この4箇所から数字を集めてこの形式の表にする」という仕組みを作れたら、月曜の2時間は「集まった数字を見て、どう動くかを考える時間」に変わります。作業が消えるだけではありません。会議でのKさんの発言は「数字を集めた人の報告」から「数字を読んだ人の提案」に変わり、周囲の見る目も変わっていきます。

大げさに聞こえるかもしれませんが、僕自身が自社サービスでやったことは本質的にこれと同じです。毎日1〜2時間の返信作業を仕組みに変えたことで、サービスの改善や発信という「考える仕事」に時間を回せるようになりました。自動化の本当の価値は、浮いた時間そのものではなく、その時間で何をできるようになるかにあります。

この分かれ目を越えるのに必要なのは、エンジニア転職でも情報収集の量でもなく、自分の業務をAIに任せられる形に分解し、小さく作って動かす経験です。正直に言うと、ここは独学だと時間がかかります。多くの受講生を見てきて、つまずく場所はだいたい同じでした。AIが書いたものが動かないとき、どこを見ればいいか分からない。動いてはいるけれど中身が分からないから、業務に使うのが怖い。ここで止まる人が本当に多いんです。

非エンジニアがこの変化に乗るための5ステップ

開発者ではない現職者が、エージェント時代に「作る側」へ回るための現実的な手順を5つにまとめます。どれも僕が受講生に実際に勧めている順番です。

Step 1：AIエージェントを一度「体感」する（今週末・30分〜）

最初の一歩は勉強ではなく体感です。Claude CodeのようなAIエージェントツールに「このWebページの内容をまとめて」「このフォルダのファイルを整理して」といった小さな仕事を丸ごと任せてみてください。「指示したら、段取りを考えて、道具を使って、勝手に進む」という感覚を一度味わうと、ニュースの見え方が変わります。

Step 2：自分の「ブラウザ作業」を棚卸しする（1時間）

1週間分の業務を振り返り、「ブラウザを開いてやっている作業」をすべて書き出します。そのうち「毎回ほぼ同じ手順」「判断がほとんど要らない」「週に合計30分以上使っている」の3条件が揃うものに印を付けてください。それがあなた専用の自動化候補リストです。

Step 3：候補を1つ選んで、小さく自動化する（週末2〜3時間×数回）

リストの中からいちばん「痛い」作業を1つだけ選び、AIと一緒に自動化してみます。僕が発信でずっと言い続けている「ビタミン剤よりも鎮痛剤を作れ」の原則です。あれば便利、ではなく、いま現に時間を奪われている痛みから着手する。ここで欲張って複数の作業を同時に狙うと、ほぼ確実に挫折します。

取り組み方の良い例・悪い例を対比しておきます。

• 悪い例：「AIで業務を全部効率化するツールを作る」。対象が広すぎて、何も完成しない
• 良い例：「毎週月曜に3つのサイトから数字を集めて表にする作業だけを自動化する」。対象が1つの痛みに絞れている

AIへの頼み方（プロンプト）にも同じ原則が当てはまります。実際に差が出る対比を載せておきます。

悪い例：丸投げで曖昧

業務を効率化するツールを作ってください。

良い例：入力・手順・出力が具体的

毎週月曜に行っている集計作業を自動化したいです。

【現在の手順】
1. 販売管理画面のCSVをダウンロードする
2. 広告管理画面で先週の消化金額を確認する
3. 2つの数字をスプレッドシートの決まった列に転記する

【作ってほしいもの】
この3手順を1コマンドで実行できる仕組み。
まず手順1だけを自動化するところから始めてください。

違いは文章力ではなく、自分の業務を手順に分解できているかどうかです。これはプログラミングというより「業務の言語化」のスキルで、現場を知っている非エンジニアこそ有利な部分です。

Step 4：動いたら「業務アプリ」に育てる（1ヶ月以内で区切る）

小さな自動化が動いたら、同僚も使える簡単な業務アプリに育てます。ポイントは開発期間を1ヶ月以内に区切ること。完璧を目指して長期化すると、モチベーションが先に尽きます。「今の機能で一度使ってもらう」を優先してください。

Step 5：社内に展開して「AIで作る人」のポジションを取る

作ったものを部署内で共有した瞬間、あなたは「AIに詳しい人」から「AIで実際に作れる人」に変わります。ここまで来ると、社内のAI活用・DX推進の相談が自然と集まり始め、キャリアの選択肢（社内での役割拡張・副業での受注）が一気に広がります。

5つのうち、Step 3までは案外なんとかなります。難所はStep 4です。「自分ひとりが使う自動化」と「同僚に配れる業務アプリ」の間には、見た目以上の距離があります。エラーへの備え、データの扱い、「なぜこう動くのか」を人に説明できること。ここを越えるには、作って終わりではなく、作ったものを分解して理解する型が要ります。ShiftBのカリキュラムで一番時間をかけているのも、この部分です。

よくある質問（FAQ）

Q1. Kitesurfは無料で使えますか？誰向けのものですか？

ベータ期間中は、CloudflareのBrowser Runというサービスを通じて無料で利用できます（アカウントごとの利用上限あり）。ただし対象はあくまで開発者・エンジニア向けのツールで、一般の人がChromeの代わりにインストールして使うものではありません。非エンジニアの方は「こういう基盤が整いつつある」という文脈を押さえておけば十分です。

Q2. プログラミング知識がない自分にも関係ありますか？

Kitesurfを直接触るのは開発者ですが、その上で動くエージェントが影響するのは全職種です。ブラウザで行う定型作業（転記・巡回・入力）を含む仕事をしているなら、無関係ではいられません。むしろ業務の中身を知っている現場の人こそ、「何を自動化すべきか」を知っている強いポジションにいます。

Q3. AIエージェントに仕事を奪われませんか？

「作業」単位で見れば、定型的なWeb作業から順に自動化されていくはずです。一方で、何を自動化するかを決め、仕組みを作り、品質に責任を持つ人の需要はむしろ増える、というのが僕の見立てです。同じ変化でも、待つ側にいるか、仕組みを作る側にいるかで意味がまったく変わります。本文の5ステップは、後者に回るための最短ルートです。

Q4. ChromeなどのブラウザのAI機能とは何が違うのですか？

ChromeのAI機能は「人間の閲覧を助ける」ためのもので、主役はあくまで人間です。Kitesurfは人間が画面を見ることを前提にしていない、AIが作業するための実行基盤で、方向性がまったく異なります。前者は快適さを、後者はコストと大量実行を最適化しています。

Q5. AIエージェントに作業を任せて、セキュリティは大丈夫なのですか？

リスクはゼロではありません。本文で触れたプロンプトインジェクションのように、エージェント特有の攻撃手法も存在します。ただ、Kitesurfが「すべてのページを信頼しない」「毎回まっさらな環境で動かす」という設計を最初から組み込んでいるように、基盤側の安全対策は急速に整備が進んでいます。利用者側の原則はシンプルで、「重要な操作（送金・削除・外部送信）は人間の確認を挟む」「試すときは業務の本番データから始めない」の2つを守ることです。

Q6. こうした動きはCloudflareだけのものですか？

いいえ。AIがブラウザやPCを操作して作業を代行する取り組みは、主要なAI企業・クラウド企業が揃って力を入れている領域です。その中でKitesurfが象徴的なのは、アプリやAIモデルの層ではなく、さらに下の「実行インフラ」の層で専用設計が始まったという点です。土台から専用品が作られ始めた分野は、その上の応用が一気に安く・当たり前になっていくのが技術の常です。

Q7. 何から学び始めるのが近道ですか？

ツールのニュースを追いかけるより、「体感 → 棚卸し → 1つ自動化」の順で手を動かすのが最短です（本文の5ステップ参照）。独学が不安な方や、自分の業務のどこから着手すべきか壁打ちしたい方は、ShiftBのAIシフトコースの無料相談会で、現在の業務内容を伺いながら一緒に整理することもできます。

まとめ — ブラウザまでもがAI専用になる時代の歩き方

最後に、この記事の要点をまとめます。

• Cloudflareが2026年8月に発表したKitesurfは、AIエージェント専用に設計されたWebブラウザ。人間向け機能を捨て、Cloudflare Workers上のV8 isolateで動く軽量設計になっている
• Chromium比でCPU消費は3.1〜3.8分の1、メモリ消費は4.7〜7分の1。速度は1.7〜1.8倍遅いが、エージェントの大量実行ではコスト優位が勝つ
• 21.5万件超のWeb標準テストに合格し、既存の自動操作ツールやMCPからそのまま使える。動画・WebGL・長時間ログインなどは今後の課題
• 本質は「インフラ企業がAIエージェントの大量実行を既定路線として整備し始めた」というシグナル。ブラウザ上の定型作業は自動化の射程に入っていく
• 非エンジニアが取るべき行動は、怯えることでも情報収集を増やすことでもなく、体感 → 棚卸し → 1つ自動化 → アプリ化 → 社内展開の5ステップで「作る側」に回ること

エージェント専用ブラウザの登場は、遠い世界の技術ニュースに見えて、実は「ブラウザで仕事をしているすべての人」の働き方に関わる地殻変動の一部です。変化の波は、待っていても止まりません。でも、波が来る方向がここまで明確に見えている今は、先回りして仕組みを作る側に回る絶好のタイミングでもあります。まずは今週末、30分だけ。AIエージェントに小さな仕事をひとつ、任せてみてください。