Codexは自然言語で触るOSラッパーになりつつある

Codexをしばらく使っていると、これは本当に「コーディングエージェント」と呼ぶだけで足りるのか、少し怪しくなってきます。コードを書くAIであることは間違いありません。ただ、実際に触っている面は、コード生成よりずっと広い。

shellを叩き、filesystemを読み、設定を見直し、browserやGUIを操作し、必要なら長い作業をGoalとして抱え、枝作業をsubagentへ切り出す。もちろん、これらは使っているCodexの画面、tool、feature flag、sandbox、approval、trust状態によって変わります。それでも、ユーザーから見ると、AIに文章でお願いしているというより、自然言語で作業環境全体を動かしている感覚が出てきます。

私にはこの感じが、かなりUnix系の運用感覚に近く見えます。正確には、CodexがUnix系OSそのものになるという話ではありません。けれど、configを育て、dotfilesのように自分の癖を固定し、/etcのような正本を守り、root権限の怖さを思い出しながら便利な自動化を増やしていく感覚がある。

この記事では、Codexを「自然言語で触るOSラッパー」として眺めます。これはOpenAI公式の製品位置づけではなく、私が自分の作業環境を見ているときの比喩です。機能紹介を並べるのではなく、なぜそう見えるのか、どこが便利で、どこに事故の匂いがあるのかを整理します。便利な道具ほど、扱いが雑だとよく刺さります。だいたい足元に。

>>>Amazonのお得な最新の情報はここ

サーバー管理者歴17年の筆者が選んだレンタルサーバーはここ

Codexは本当にただのコーディングエージェントなのか

Codexは、入口としてはコーディングエージェントです。リポジトリを読み、修正案を出し、テストを回し、差分を作る。その説明だけなら、従来の開発支援AIの延長に見えます。

しかし実際の作業では、Codexが扱う対象はコードだけに閉じません。ファイル、設定、ログ、ブラウザ、ローカルアプリ、外部ツール、作業手順、権限境界まで含めて、ひとつの作業面として動きます。ここから、単なる「AIにコードを書かせる」感覚が少しずつ変わっていきます。

表向きはコードを書くAIとして見える

最初に見えるCodexは、かなり分かりやすい存在です。バグを直して、関数を書いて、テストを追加して、PRの説明まで整える。名前の通り、コードのための相棒に見えます。

この段階では、読者が想像する危険も比較的シンプルです。間違ったコードを書くかもしれない。テストが足りないかもしれない。既存仕様を読み違えるかもしれない。どれも普通の開発支援ツールとしてのリスクです。

ただ、Codexの本体は「コードを書く文章生成器」ではありません。作業ディレクトリを持ち、許可された範囲でコマンドを実行し、ファイルを編集し、ブラウザやアプリの状態まで見に行ける実行環境です。文章で頼んだ結果として、現実の作業環境が変わります。

実際にはshell、filesystem、browser、GUIへ触れる

Codexが強くなるほど、触る面は広がります。shellでコマンドを実行し、filesystem上のファイルを読み書きし、browserでローカルアプリを確認し、必要ならGUIアプリも操作する。もはや「コードを返すAI」ではなく、作業環境の中に入って動く存在です。

この違いはかなり大きいです。チャットだけのAIなら、最悪でも間違った説明を返すだけで止まります。ところがCodexは、設定されたsandboxやapprovalの範囲内で実際にファイルを変更できます。コマンドも実行できます。設定を変えれば、次回以降の動作にも影響します。

だから、Codexを使うときの感覚はIDE拡張だけでは説明しきれません。IDEの中にいるのではなく、shellとfilesystemとbrowserとGUIをまたいでいる。ここで急に、作業環境そのものを扱っている感じが出てきます。

自然言語でOS資源を動かす感覚が出てくる

面白いのは、ユーザーがその操作を自然言語で行うことです。「この差分を確認して」「ローカルで起動して」「ブラウザで見て」「失敗したテストを直して」と頼むと、Codexは複数の道具をまたいで作業します。

これは、GUIのボタンを押すのとも、shellで一行ずつ打つのとも違います。自然言語が、OS資源や開発環境への上位インターフェイスになっている。大げさに言えば、言葉がshellの上に乗っている状態です。そこに、従来の操作体系とは別の怖さがあります。

そして自然言語は、強い操作を妙に柔らかく見せます。chmod や git のコマンドなら一瞬身構える人でも、「権限まわりを整えて」「履歴をきれいにして」と言うと、重さが見えにくい。ここがCodexの便利さであり、同時に運用設計が必要になる理由です。

「整理して」で履歴まで片づけ始めたら、それはもう別の仕事です。

もちろん、CodexはOSではありません。プロセス管理もメモリ管理もカーネル空間も担っていません。ただ、ユーザーから見た操作面としては、OSに載った複数の資源を自然言語でまとめて触るラッパーに近づいています。ここを見落とすと、便利さだけ見て権限の重さを忘れます。

なぜUnix系を触っている感覚になるのか

私がCodexにUnix系っぽさを感じるのは、懐古趣味だけではありません。FreeBSDの公開サーバーを10年以上rootで運用していた（ここでいうrootは管理者権限側の責任という意味です。suやsudoを知らない話ではありません、念のため）感覚から見ると、Codex環境には「自分で育てる作業面」と「事故ると痛い権限面」が同居しています。いまの日常環境はmacOSです。macOSは認証文脈ではUNIXとして語れる面がありますが、この記事でいうUnix系の手触りは、主にFreeBSDでのroot/サーバー運用と、BSD/Linux/shell/config/job-controlをまたぐ広い運用文化から来ています。

Unix系らしさというのは、黒い画面が出てくるという意味ではありません。設定ファイルがあり、小さな道具を組み合わせ、hooksで lifecycle に割り込み、dotfilesのように自分の作法を残し、root的な責任を背負う。そういう運用の匂いです。

設定ファイルを育てる感覚

Unix系の環境では、設定ファイルを育てることが作業環境を育てることでした。shellの設定、エディタ設定、cron、各種rcファイル、dotfiles。最初は小さな設定でも、積み上がるとその人の作業OSになります。

Codexにも似た面があります。configで機能を有効にし、AGENTS.mdでルールを書き、skillsやpluginsで作業手順を増やし、hooksで起動時や停止時の振る舞いを追加する。これは単なる「設定画面をいじる」話ではありません。

設定が増えるほど、Codexは初期状態のツールではなくなります。自分の仕事、自分の禁止事項、自分の文章の癖、自分の検証手順を知った環境になっていく。dotfilesを育てていた人なら、この感じはかなり分かるはずです。

しかも、Codexの設定は個人の気分だけでなく、実行境界にも関わります。どのPythonを使うか、どのブラウザモードを使うか、どのpluginを正本として扱うか。こうした指定は、見た目はdotfilesでも、効き方としては /etc 配下の運用設定に近いところがあります。

hooksや自作スクリプトが作業環境を変えていく

Unix系の運用では、cronやhookや自作スクリプトが環境を変えていきます。定期実行する。ログを集める。起動時に状態を整える。特定の操作に合わせて補助処理を走らせる。うまく使えば強力ですが、何がいつ動くか分からなくなると急に怖い。

Codexのhooksにも同じ緊張感があります。SessionStart、UserPromptSubmit、Stopのような lifecycle に処理を差し込めるなら、それは便利機能であると同時に、作業環境の深いところへ触る仕組みです。状態取得、memory保存、検証、通知などを自動化できる一方で、無自覚に増やすと原因追跡が難しくなります。

ここで重要なのは、hookを「なんか便利な自動実行」として扱わないことです。いつ走るのか。何を書き込むのか。外部送信はあるのか。失敗したときに作業へどう影響するのか。cronに雑なスクリプトを置くと後で自分が困る、あの古典的な話が帰ってきます。

root運用に似た便利さと怖さ

FreeBSDの公開サーバーをrootで触っていたころ、便利さと怖さはいつも隣にありました。rootなら何でもできます。だからこそ、間違えると何でも壊せます。権限が強い環境では、「できる」と「やってよい」は別物です。

Codexにも、これに似た責任があります。もちろんCodexが常にroot権限を持つわけではありません。それでも、ユーザーの作業ディレクトリでファイルを変え、コマンドを走らせ、ブラウザやGUIへ触れるなら、影響範囲はチャットの外へ出ます。

自然言語で頼めるぶん、危険はむしろ見えにくくなります。shellなら rm や git reset を打つ瞬間に手が止まることがあります。自然言語では「整理して」「不要なもの消して」と言えてしまう。柔らかい言葉で硬い操作を頼めるのが、ちょっとした罠です。

config.tomlとAGENTS.mdは何に見えるか

Codex環境を見るうえで、configとAGENTS.mdは中心にあります。config.tomlは機能や挙動の設定、AGENTS.mdは作業方針を永続化する入口です。この2つを単なるメモや便利設定として扱うと、環境が育つほど管理が曖昧になります。

私の運用では、config.tomlはOSやdaemonの設定に近く、AGENTS.mdはdotfilesであり、場合によっては /etc 配下の方針ファイルに近いものとして扱っています。ただし、これは私のローカル憲法としての読み方です。公式に確認できるのは、AGENTS.mdにはglobalとprojectの階層があり、より近い指示が広い指示を上書きする、というinstruction layeringです。

config.tomlは機能フラグと挙動設定

config.tomlは、Codexの機能フラグや基本挙動を置く場所です。sandbox、approval、hooks、skills、agents関連の設定など、どの機能を有効にし、どの境界で動かすかに関わります。ここは「ちょっとした好み」だけでは済みません。

たとえばhooksやGoalのような機能は、使い方によって作業の性質を変えます。単発の応答から、lifecycleに沿った自動処理へ。短い依頼から、長時間の目的追跡へ。configで有効にするものは、Codexの操作面そのものを変えます。

Unix系の設定ファイルを触るとき、変更はだいたい地味です。しかし効き方は地味ではありません。1行の設定で、起動時の挙動や権限や探索範囲が変わる。Codexのconfigも同じで、目立たない場所ほど運用上は強いことがあります。

AGENTS.mdは公式には階層化された指示である

AGENTS.mdは、Codexに永続的な作業指示を渡すためのファイルです。globalな指示、projectごとの指示、より局所の指示があり、近い階層ほどそのスコープでは強く効く。ここまでは公式のlayeringとして捉えられます。

この性質だけでも十分に重要です。どういう文体で答えるか、どのファイルを読むか、どの操作を避けるか、テストをどう回すか。毎回の会話で言い直すより、作業面の近くへ置いたほうが安定するルールがあります。

一方で、「AGENTS.mdは憲法でありSSOTである」という言い方は、私の運用上の強い方針です。公式仕様の言葉そのものではありません。私は、重要な運用判断を会話履歴や雑なメモへ散らさず、AGENTS.mdや該当するplugin contract、schema、source fileへ寄せることで、次回以降の読み違いを減らしています。

正本の置き場所を分けることが運用を守る

Codexのような環境では、正本境界が崩れると事故が増えます。会話では「今回はこうしよう」と言い、READMEには別の手順があり、AGENTS.mdにはさらに別の禁止事項がある。人間でも迷います。AIならなおさら、都合のよい解釈へ滑ります。

だから、憲法的な決定はAGENTS.mdへ集約する。plugin固有ならpluginの契約へ置く。記事生成workflowならそのcontractへ置く。実装仕様ならsource fileやschemaへ置く。正本の置き場所を分けること自体が、運用の安全策になります。

これは堅苦しい話に見えますが、実際は作業を楽にします。毎回「前に言ったよね」を繰り返さなくて済む。Codexも迷いにくい。人間も後で読み返せる。憲法は自由を殺すためではなく、毎回の口頭注意を減らすためにあります。そこは少し地味ですが、かなり効きます。

AIでBLOGの可能性を探る

AGENTS.md、ちゃんと書いたのに全然言うこと聞かないんだけど？ | AIでBLOGの可能性を探る 最近、Context Engineering という言葉をよく見るようになりました。 プロンプトを書くのではなく、AI が見る情報空間そのものを設計する。システムプロンプト、ナレッジ、…

hooks、skills、pluginsはuserland拡張に近い

Codexの拡張機構は、Unix-likeなuserland文化に近い見え方をします。カーネルそのものを変えるのではなく、周辺に小さな道具や作業契約を置き、必要な場面で呼び出す。道具が増えるほど、素のCodexではなく、自分用の環境になります。

ここで大事なのは、hooks、skills、pluginsを同じ箱に入れないことです。hooksはlifecycleへの割り込み、skillsは作業手順や専門知識の入口、pluginsは能力やworkflowを束ねる単位です。役割が違うから、壊れ方も違います。

hooksはライフサイクルへの割り込み

hooksは、Codexの特定のタイミングに処理を差し込む仕組みです。セッション開始、ユーザー入力、停止時など、作業の節目に自動処理を走らせる。これはUnix系の運用で言えば、起動スクリプトやcronや各種hookに近い感覚です。

便利な使い方は多いです。作業前にmemoryを検索する。終了時に短い要約を保存する。特定条件で検証を促す。こうした処理は、毎回手でやるより環境へ寄せたほうが安定します。

一方で、hookは「見えないところで動く」性質を持ちます。だから、どのhookが有効で、どのlayerに定義され、trust条件がどうなっているかを確認する必要があります。定義されているだけで、今この作業で確実に動いているとは限らない。ここを雑に扱うと、動いていると思った安全装置が動いていない、という実に味わい深くない状況になります。

skillsは作業手順と専門知識の入口

skillsは、特定の作業に入るための手順書兼契約です。画像生成、ドキュメント編集、Slack、Google Drive、Agentic StructCivのように、タスクごとの読み方や禁止事項、使うべきtoolを固定します。

これは、Unix系の運用で言えばコマンド群やrunbookに近い。tarにはtarの作法があり、sshにはsshの危険があり、バックアップ手順にはバックアップ手順の停止条件があります。skillsは、そうした文脈をCodexへ渡す入口です。

重要なのは、skillを「便利な追加知識」ではなく、発火条件を持つ実行契約として扱うことです。たとえば記事生成workflowのskillなら、どのartifactを正本にするか、どの段階で止まるか、どのレポートをLLMが作るべきかを決めます。そこを無視すると、workflowではなく気分になります。

pluginsはworkflowを束ねる拡張単位

pluginsは、skills、app連携、MCP serverなどを束ねる単位です。pluginの作り方によっては、scripts、schemas、assets、hooksなども含められます。単体の作業手順というより、ひとつの能力セットやworkflowを配布・実行する形に近い。

たとえば記事制作pluginなら、intake、blueprint、outline、draft、editorial review、decoration、WordPress handoffまでをartifactと契約でつなげます。画像系pluginなら、prompt、生成物、ALT、previewを扱う。pluginは機能の寄せ集めではなく、責任境界を持った作業環境の一部です。

ただし、pluginにはsourceとcacheの境界があります。公式には、インストール済みpluginはcache側のコピーから読み込まれる。私のローカル運用ではさらに、正本pluginディレクトリを一次編集先にし、cacheは反映先として扱う、と決めています。この2つを混ぜると、直したつもりの変更が反映されなかったり、cache側だけが妙に育ったりします。環境が賢くなるほど、正本の場所を間違えると人間が静かに負けます。

Goalとsubagentはjob controlに見える

Goalとsubagentは、CodexがOSラッパーに見える理由の中でもかなり強い部分です。Goalは長時間の目的追跡、subagentは枝作業や隔離されたworkerに近い。Unix系のjob controlやbackground processを思い出します。

もちろん、fgやbgをそのまま使うわけではありません。Goalは実験的な機能で、利用面や設定に依存します。subagentもOSプロセスではなく、明示的に起動される別の作業スレッドに近いものです。それでも、「本筋とは別に走る作業」「完了条件まで継続する作業」「親が結果を統合する作業」が出てくると、単発応答のAIとは違う管理が必要になります。

Goalは走らせる前に停止条件を持つ

Goalは、短い質問への回答ではなく、目的完遂へ向かう長時間タスクとして見たほうが自然です。記事を最後まで作る。CIを直す。複数段階のworkflowを進める。途中で検証し、状態を見て、次の工程へ進む。

これは非常に便利です。ユーザーが細かく指示し続けなくても、Codexが目標に向かって作業を継続できる。作業の途中でコンテキストが整理され、必要なartifactが積み上がっていくなら、かなり強い実行環境になります。

しかし、長時間プロセスには停止条件が必要です。何を達成するのか。何を変更しないのか。進捗をどう検証するのか。何が起きたら止まるのか。外部送信、削除、Git履歴変更、運用正本変更のような境界を越えてよいのか。ここを曖昧にしたGoalは、便利な自律性ではなく、目的の薄いプロセスになります。だいたいCPUではなくトークンを食べます。

subagentは枝作業を隔離するbackground taskに近い

subagentは、本筋から分けたほうがよい調査や生成を任せるworkerに近い存在です。本文生成、DOM観測、ログ読解、画像prompt、監査、比較表作成のように、主スレッドへ生データを流し込むと重くなる作業を隔離できます。

この発想は、Unix系のbackground jobや小さなプロセス分割に似ています。親プロセスが全てを抱え込まず、子に仕事を渡し、結果だけ受け取る。親は方針と統合に集中する。うまく使えば、コンテキストも判断も散らかりにくくなります。

ただし、subagentも魔法ではありません。明示的に何を渡すのか、何を返させるのか、どこまでを担当させるのかを決めないと、同じ調査を重複したり、親と子で前提がズレたりします。サブに任せると言いながら親が全部やるのも、運用としてはだいぶ気まずい。人間の職場でも似たことがありますが、ここではやめておきます。

job controlとして見るなら観測、停止、復帰を決める

Goalやsubagentをjob controlとして見るなら、重要なのは「走らせられること」ではありません。今どのjobが動いているのか、誰が結果を統合するのか、どこで止めるのか、失敗したらどこから復帰するのかです。

Unix系のjob controlなら、backgroundで走らせたjobを jobs で見て、必要なら fg へ戻し、危なければ止めます。Codexでも同じ発想が要ります。進行中のGoal、委任中のsubagent、親スレッドの責務、生成されたartifact、まだ越えていないpermission boundaryを観測できないと、便利な並列化はすぐに散らかります。

だから、長時間作業には最初から短い契約を置くべきです。scope、変更禁止範囲、validation、stop condition、report cadence、外部操作の確認境界。これがあると、Codexは走るだけでなく、止まるべき場所で止まれます。走っていることより、止められることのほうが運用では大事です。

自然言語OSラッパーには憲法が必要になる

Codexを自然言語OSラッパーとして見るなら、憲法は長文の心得集ではなく、短く効く実行契約です。ここでいう憲法とは、AGENTS.mdや該当するSKILL.md、plugin contractに置く、禁止事項、優先順位、正本境界、検証条件、停止条件のことです。

自然言語は柔らかい入力です。だからこそ、硬い境界を別に持つ必要があります。何をしてよいか、何をしてはいけないか、迷ったらどちらへ倒すか。これを毎回の会話だけに任せると、作業が長くなるほどブレます。

曖昧な依頼は最小範囲へ畳む

「任せた」は便利な言葉です。人間同士でもよく使います。けれどCodexに対しては、無制限の裁量として扱わせるべきではありません。とくにGoalやsubagentを伴う長時間実行では、曖昧な自律指示がそのまま作業拡大につながります。

「いい感じに整理して」は、ファイル移動や削除を含むかもしれません。「全部やって」は、外部送信やWordPress操作まで含むように見えるかもしれません。「完遂して」は、どのartifactを完成と見るかが分かりません。人間の雑な日本語は便利ですが、権限を持つ実行環境にはやや刺激が強い。

だから、曖昧な依頼を受けたときは、最小範囲、検証可能な完了条件、明示的な停止条件へ畳む。たとえば「全部やって」を、「reportsを作るところまで。外部送信、削除、Git履歴変更、WordPress保存や公開が必要なら停止」と読み替える。こうして初めて、自律性が運用可能な形になります。

憲法に書くのはスローガンではなくチェックリスト

AGENTS.mdへ書くべきなのは、「安全にやる」「丁寧にやる」のような願いではありません。Codexが実行時に判定できる条件です。スローガンは気分を整えますが、ファイルは守りません。

最低限、scope、completion condition、validation method、stop condition、forbidden boundaries、source of truthを置きます。scopeは触ってよい範囲。completion conditionは何ができたら終わるか。validation methodはテスト、lint、schema check、目視確認などの確かめ方。stop conditionは外部送信、削除、公開、認証、課金、正本変更のような停止線です。

このチェックリストは、Codexを縛るためではありません。自然言語の曖昧さを、実行環境が扱える形に変換するためです。「たぶんこれでよい」を減らし、「ここまでなら進める、ここからは聞く」を増やす。地味ですが、ここが作業OSとしての使いやすさを決めます。

AGENTS.mdは事故を防ぐための操作面である

AGENTS.mdにルールを書くと、面倒で堅い環境になるように見えるかもしれません。実際には逆です。よく使う判断を憲法に落とすほど、毎回の説明が減り、Codexが迷いにくくなり、危険なところで止まりやすくなります。

たとえば、裸のpythonを使わない、正本pluginだけを編集する、cacheを一次編集先にしない、WordPress公開は押さない、GUI操作は指定モードを守る。こうしたルールは、一度書いておけば毎回の作業で効きます。

とくにSSOTの指定は効きます。AGENTS.md、SKILL.md、plugin contract、schema、source fileのどれが正本なのかを決めておくと、Codexは「たぶんこれでよい」ではなく「ここに従う」と判断できます。AIに自由を渡すなら、自由の基準をどこかに固定しておく必要があります。

ブロガーがCodex環境を育てる意味

ここまでUnix系の運用、root、job controlの話をしてきましたが、これは職業エンジニアだけの話ではありません。むしろ、現在の私の主戦場はブログ、SEO、WordPress、SWELLです。その現場でも、Codexを作業環境として育てる意味はかなり大きい。

記事を書く、構成を作る、装飾を整える、WordPressへ渡す、画像やALTを管理する、SEO意図を確認する。こうした作業は、コードではなくても十分に複雑です。だからこそ、自然言語で動くOSラッパーには運用設計が必要になります。

主戦場がブログでも工程分離は必要になる

ブログ運営は、文章を書くだけの仕事ではありません。キーワードを見て、読者を決め、構成を作り、本文を磨き、装飾し、画像を扱い、WordPressやSWELLの仕様に合わせ、公開前の確認をします。地味に工程が多い。

Codexは、この工程をかなり支えられます。記事のblueprintを作る。outlineを作る。draftを書く。editorial reviewへ回す。publish.htmlを作る。WordPress投入の手前で止める。こうした流れは、もはや単なる文章生成ではなくworkflowです。

ただし、workflowにした瞬間、全部を同じ権限で扱ってはいけません。記事生成は下書き作成、SWELL装飾は表示構造の変更、画像採用は視覚情報と権利・文脈の判断、ALTはSEOとアクセシビリティ、WordPress貼り付けは外部CMS操作、保存は永続変更、公開は読者に見える送信です。同じ「記事作業」でも、境界は別物です。

WordPressとSWELLでは保存と公開を分けて考える

ブロガーにとって重要なのは、Codexに任せる範囲を工程ごとに切ることです。本文生成までは自動でよい。SWELL装飾はHTMLやブロック構造を確認してから採用する。画像とALTはセットで見て、記事意図とズレていないか確認する。WordPressへの貼り付けは実行しても、保存や公開は別の許可にする。

この分離は慎重すぎる話ではありません。WordPressでは、貼り付け、下書き保存、画像挿入、公開がそれぞれ違う重さを持ちます。Codexがコードエディタへ本文を入れることと、公開ボタンを押すことは、同じ自動化ではありません。公開ボタンだけは、妙に重い一粒です。

その一粒だけ、急に重力が増すんですよね。

SWELL装飾も同じです。装飾は読みやすさを上げますが、本文の意味やCTAの見え方も変えます。だから、装飾済みartifact、画像、ALT、WordPress貼り付け、保存、公開を分けておく。境界を分けるほど、Codexは速く動ける場所で速く動き、人間が見るべき場所で止まれます。

Codexを自分用の作業OSとして育てる

CodexをOSラッパーとして見ると、育て方が変わります。新しい機能を増やす前に、正本を決める。自動化する前に、停止条件を決める。subagentへ任せる前に、入力と出力を絞る。Goalを使う前に、完了条件と禁止範囲を書く。

この発想は、派手ではありません。けれど長く効きます。dotfilesを整えた環境が毎日の作業を少しずつ楽にするように、AGENTS.mdやskillsやpluginsを整えたCodex環境は、次の作業を少しずつ安全にします。

Codexは、コードを書くAIでありながら、自然言語で作業OSを触る入口になりつつあります。だからこそ、便利さだけでなく、憲法、config、hooks、Goal、subagent、正本境界まで含めて考えたほうがいい。最後に残るのは、新機能の数ではなく、自分が安心して任せられる環境かどうかです。そこを雑にすると、未来の自分がとても丁寧に怒ります。