概要: 本記事では、Dockerの基本的な導入方法から、OSごとの具体的な手順、活用事例を解説します。また、利用上の注意点やPodmanなどの代替ツールについても触れ、Dockerを効果的に利用するためのヒントを提供します。
Docker導入の全体像と最短経路:環境構築の基本
なぜ今、Dockerの導入が求められるのか?
現代のソフトウェア開発において、Dockerはもはやデファクトスタンダードと化しつつあります。その背景には、開発チーム間で頻発する「私の環境では動くのに…」といった環境差異の問題を根本的に解消できる利点があります。アプリケーションとその依存関係を「コンテナ」という自己完結型のパッケージにすることで、開発からテスト、本番環境まで、どのステージにおいても一貫した動作を保証します。これにより、開発者は環境構築の手間から解放され、本来の業務であるアプリケーション開発に集中できるようになります。
国内企業においても、コンテナ技術の利用や導入検討は本格的な普及期にあり、2021年2月時点の調査では、国内企業・組織の40.2%がコンテナの利用・導入を進行中であるとIDC Japanが報告しています。この数値は年々増加傾向にあり、生産性の向上やマイクロサービスアーキテクチャへの対応といった、現代の開発が求める要件に応えるための不可欠なツールとして認識されています。
また、総務省の2024年度調査によれば、日本企業のDX課題として「人材不足」を挙げる割合が48.7%に上ります。Dockerのようなツールは、環境構築の属人性を排除し、新しい開発者のオンボーディングを効率化することで、この人材不足問題への間接的な対策としても機能し得ると考えられます。開発プロセスの標準化と効率化は、現代の企業が競争力を維持・向上させる上で欠かせない要素です。
Dockerの基本概念と導入メリットの理解
Dockerは、アプリケーションを「コンテナ」と呼ばれる軽量な仮想環境で実行するためのプラットフォームです。従来の仮想マシン(VM)がOS全体を仮想化するのに対し、コンテナはOSのカーネルをホストと共有し、アプリケーションとその実行に必要なライブラリ、設定ファイルのみをパッケージ化します。これにより、起動が非常に高速で、リソース消費も抑えられます。Dockerイメージは、アプリケーションの実行環境を定義した設計図であり、このイメージから複数のコンテナを起動できます。
Docker導入のメリットは多岐にわたります。第一に、環境構築の簡素化と統一です。開発者ごとに異なるOSやミドルウェアのバージョンに起因する問題を解消し、全員が同じ環境で開発を進められます。第二に、開発サイクルの高速化です。アプリケーションのビルド、テスト、デプロイがコンテナベースで行えるため、CI/CDパイプラインとの親和性が高く、素早いリリースを可能にします。第三に、スケーラビリティの向上です。コンテナは移植性が高いため、必要に応じて容易に複製・デプロイでき、アクセス増大時にも柔軟に対応できます。これらのメリットは、現代の迅速なビジネス要求に応える上で非常に重要です。
Dockerを導入する際は、これらの基本概念をチーム全体で共有し、Dockerが提供する価値を理解することが成功への第一歩となります。単なる技術導入に留まらず、開発プロセス全体の改善ツールとして捉える視点が重要です。
最短経路でDocker環境を立ち上げるための準備
Docker環境を最短で立ち上げるには、まずお使いのOSに応じたDocker Desktop(Windows, macOS)またはDocker Engine(Linux)のインストールが基本となります。特にWindowsユーザーの場合、WSL 2(Windows Subsystem for Linux 2)の有効化が推奨されます。WSL 2を利用することで、LinuxベースのDocker環境をWindows上でネイティブに近いパフォーマンスで実行でき、安定性と互換性が格段に向上します。
インストール後、コマンドプロンプトやターミナルでdocker run hello-worldを実行し、Dockerが正常に動作するかを確認しましょう。このコマンドが成功すれば、基本的なDocker環境は整っています。次に、既存のプロジェクトや学習用の簡単なアプリケーションをDockerized(Docker化)してみることをお勧めします。Dockerfileを作成し、アプリケーションの依存関係や起動コマンドを記述することで、独自のイメージをビルドし、コンテナを起動する一連の流れを体験できます。
初心者の場合、まずはDocker Composeを使って複数のサービスをまとめて管理する方法を学ぶと良いでしょう。Webアプリケーションとデータベースなど、関連するコンテナ群をdocker-compose.ymlファイル一つで定義し、docker compose upコマンドで一括起動できるため、より実践的な開発環境を手軽に構築できます。オンラインのチュートリアルや公式ドキュメントを活用し、実際に手を動かすことが習得への最短経路となります。
出典:IDC Japan、総務省
主要OS別Docker導入手順:Windows/Mac/Linuxでのセットアップ
WindowsにおけるDocker DesktopとWSL2の活用
Windows環境でDockerを導入する最も一般的な方法は、Docker Desktopの利用です。Docker Desktopは、Windowsのデスクトップ環境にDocker Engine、Docker CLI、Docker Compose、Kubernetesなどを統合して提供するパッケージです。インストールは、公式サイトからインストーラーをダウンロードし、指示に従って進めるだけで完了します。ただし、Windows 10/11 Homeでも利用可能ですが、WSL 2(Windows Subsystem for Linux 2)の有効化が必須となります。
WSL 2を事前に有効化することで、Docker DesktopはLinuxのカーネルをベースにDockerコンテナを実行するため、Windows上でありながら高いパフォーマンスと安定性を享受できます。WSL 2の有効化手順は、Windowsの機能設定から「Linux用Windowsサブシステム」と「仮想マシンプラットフォーム」を有効にし、Microsoft StoreからUbuntuなどのLinuxディストリビューションをインストールするという流れになります。その後、WSL 2を既定のバージョンに設定し、Docker Desktopのインストーラーを実行すればスムーズに導入が進みます。
導入後は、Docker Desktopの設定画面でWSL 2統合が有効になっていることを確認し、どのWSL 2ディストリビューションでDockerリソースを共有するかを選択します。これにより、Windowsの任意のターミナル(PowerShell, コマンドプロンプト, WSL 2のBashなど)からdockerコマンドを実行できるようになり、WindowsとLinux環境の両方でコンテナを効率的に管理できる環境が整います。
MacにおけるDocker Desktopの導入とApple Silicon対応
macOS環境でも、Windowsと同様にDocker Desktopを利用するのが最も推奨される方法です。Mac版のDocker Desktopは、Macのネイティブ環境に最適化されており、簡単にDocker環境を構築できます。公式サイトからMac用のインストーラーをダウンロードし、アプリケーションフォルダにドラッグ&ドロップするだけでインストールが完了します。初回起動時には、必要なコンポーネントのセットアップが行われます。
特に、Apple Silicon(M1/M2/M3チップなど)を搭載したMacを使用している場合でも、Docker DesktopはApple Siliconにネイティブ対応しており、高いパフォーマンスでコンテナを実行できます。従来のIntel Macと比較しても、ビルド時間やコンテナの起動速度が大幅に向上しており、非常に快適な開発体験を提供します。Docker Desktopは、Rosetta 2を必要とせずにARMアーキテクチャ上で直接動作するため、互換性やパフォーマンスの心配はほとんどありません。
インストール後は、Docker Desktopのメニューバーアイコンをクリックして、ステータスを確認できます。また、設定画面ではリソース割り当て(CPU, メモリなど)の調整や、Kubernetesの有効化などが行えます。Macのターミナルを開き、docker run hello-worldコマンドを実行して動作を確認すれば、すぐにDockerを用いた開発を開始できます。Mac独自の開発環境との連携もスムーズに行えるため、デザイナーやフロントエンドエンジニアにとっても手軽に環境構築が可能です。
LinuxにおけるDocker Engineのインストールと設定
Linux環境では、Docker Desktopではなく「Docker Engine」を直接インストールするのが一般的です。Docker Engineは、Dockerのコアコンポーネントであり、Linuxのコマンドラインを通じてDockerを操作します。インストール手順は、使用しているLinuxディストリビューション(Ubuntu, CentOS, Debianなど)によって異なりますが、基本的には公式ドキュメントに沿ってリポジトリを追加し、パッケージマネージャー(apt, yumなど)でインストールします。
例えばUbuntuの場合、以下の手順でインストールを行います。まず、既存のDockerパッケージをアンインストールし、必要な依存関係をインストールします。次に、Dockerの公式GPGキーを追加し、aptリポジトリをセットアップします。最後に、sudo apt updateを実行し、sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-pluginコマンドでDocker Engineをインストールします。インストール後、sudo systemctl start dockerでDockerサービスを起動し、sudo systemctl enable dockerで自動起動を設定します。
注意点として、Dockerコマンドをroot権限なしで実行するためには、カレントユーザーをdockerグループに追加する必要があります。sudo usermod -aG docker $USERコマンドを実行し、一度ログアウトしてから再ログインすることで、dockerコマンドをsudoなしで実行できるようになります。この設定はセキュリティと利便性の両面で重要です。Linux環境では、デスクトップ環境のGUIツールに依存せず、コマンドラインによる詳細な制御が可能となるため、サーバーサイド開発やCI/CD環境での利用に適しています。
Dockerでできることと具体的な活用例:デスクトップ利用から開発環境まで
開発環境の統一と環境構築の劇的な簡素化
Dockerが提供する最も基本的な価値の一つは、開発環境の統一と構築の簡素化です。チーム内の開発者ごとに異なるOS(Windows、macOS、Linux)やミドルウェアのバージョン、インストールされているライブラリの差異は、しばしば「環境依存のバグ」として開発効率を著しく低下させます。Dockerを用いることで、これらの問題を根本から解決できます。プロジェクトに必要な全てのソフトウェア(データベース、Webサーバー、プログラミング言語ランタイム、各種ライブラリなど)を一つのDockerfileに記述し、イメージとして共有することで、誰でも一貫した開発環境を数分でセットアップ可能になります。
具体的な活用例としては、新しいプロジェクトメンバーが加わった際、複雑な手順書に従って手動で開発環境を構築する代わりに、docker compose upコマンド一つで必要な環境がすべて立ち上がるようになります。これにより、オンボーディングの時間を大幅に短縮し、すぐに開発業務に取り掛かれるようになります。また、複数のプロジェクトを並行して開発する場合でも、それぞれのプロジェクトが独立したコンテナ内で動作するため、依存関係の衝突やバージョンの競合といった問題に悩まされることがなくなります。これにより、開発者は安心して様々な技術スタックを試すことができ、生産性の向上に直結します。
この環境統一のメリットは、開発環境に留まりません。テスト環境や本番環境も同じDockerイメージをベースに構築できるため、開発中に再現性のないバグが発生するリスクを低減し、デプロイ時の予期せぬトラブルを未然に防ぐことにも貢献します。一貫した環境は、品質保証の観点からも極めて重要です。
マイクロサービスアーキテクチャとCI/CDパイプラインとの連携
Dockerは、マイクロサービスアーキテクチャと継続的インテグレーション/継続的デリバリー(CI/CD)パイプラインと非常に高い親和性を持ちます。マイクロサービスアーキテクチャでは、一つの巨大なアプリケーションを複数の独立した小さなサービスに分割します。これらのサービスをそれぞれDockerコンテナとしてデプロイすることで、サービスの独立性を保ちつつ、開発・デプロイ・スケーリングを柔軟に行うことが可能になります。
具体的には、各マイクロサービスを個別のDockerfileで定義し、CI/CDパイプライン上でそれぞれのサービスイメージをビルド、テスト、レジストリにプッシュします。その後、Kubernetesのようなコンテナオーケストレーションツールと連携することで、各サービスのデプロイ、負荷分散、自動スケーリング、サービスディスカバリなどを効率的に管理できます。これにより、開発チームは各サービスの開発に専念でき、サービス間の依存関係に起因するデプロイリスクを軽減できます。問題が発生した場合でも、特定のサービスだけを更新・ロールバックすることが容易になり、システム全体の可用性向上に貢献します。
CI/CDパイプラインにおいては、Dockerコンテナがビルド環境として活用されることもあります。例えば、特定の言語のコンパイラやテストツールを含むDockerイメージをCI/CDエージェント上で実行し、その中でソースコードのビルドやテストを行うことで、CI/CD環境自体の環境依存をなくし、パイプラインの安定性と再現性を高めることができます。このような連携により、ソフトウェア開発の全体像がよりスムーズかつ堅牢なものとなります。
デスクトップ利用から学習・実験環境としての活用
Dockerの活用範囲は、プロの開発環境やサーバーサイドのデプロイに留まらず、個人のデスクトップ利用や学習・実験環境としても非常に有用です。例えば、新しいプログラミング言語やフレームワークを試したい場合、システム全体を汚すことなく、Dockerコンテナ内で安全に環境を構築できます。試用後に不要になれば、コンテナを削除するだけでクリーンな状態に戻せるため、手軽に様々な技術スタックを検証できる点が大きなメリットです。
具体的なデスクトップ利用の例としては、WordPressやJoomla!のようなCMSをローカル環境で立ち上げてテーマ開発を行ったり、MongoDBやPostgreSQLといったデータベースを一時的に起動してアプリケーションの動作確認を行ったりする場面が挙げられます。Docker Composeを使えば、Webサーバー、データベース、アプリケーション本体といった複数のコンポーネントを一度に起動できるため、複雑な環境も容易に再現可能です。また、古いバージョンのソフトウェアが必要な場合でも、ホストOSに影響を与えることなく、特定のバージョンをコンテナ内で隔離して実行できます。
さらに、教育目的や技術ブログの執筆、OSSプロジェクトへの貢献など、多様なシーンでDockerは学習・実験の強力なツールとなります。公式イメージとして提供されている豊富なソフトウェアを組み合わせることで、アイデアを素早く形にし、失敗を恐れずに新しい挑戦ができる環境が手に入ります。デスクトップアプリケーションやIoTデバイスの開発においても、Dockerのコンテナ技術は、再現性の高い開発・テスト環境を提供し、開発効率を向上させる可能性を秘めています。
Docker利用時の落とし穴と代替案:Podmanの検討も
Docker Desktopのライセンス変更と企業利用における注意点
Dockerは多くの開発現場で広く利用されていますが、近年、Docker Desktopのライセンス変更が企業利用に大きな影響を与えています。2021年8月以降、Docker Desktopは特定の企業規模(従業員数250人以上、または年間売上高1,000万ドル以上)において有料化されました。個人利用、教育機関、小規模企業は引き続き無料で利用できますが、企業で導入を検討する際には、必ずライセンス規定の確認が必須となります。これを怠ると、コンプライアンス違反となる可能性があります。
ライセンス費用はサブスクリプション形式で提供されており、規模に応じて複数のプランが用意されています。企業がDocker Desktopを継続して利用する場合、これらのコストを考慮に入れ、予算計画を立てる必要があります。また、ライセンス変更に伴い、無料版から有料版への切り替えが必要なケースでは、移行プロセスや管理者によるライセンス管理体制の構築も検討事項となります。このライセンス変更は、代替ツールの台頭を促す一因ともなりました。
ライセンスの確認だけでなく、Docker Desktop自体がシステムリソースを消費することや、アップデートによる挙動の変化なども考慮すべき注意点です。特に、大規模な開発チームや複数のプロジェクトでDockerを利用する場合、安定性とコストの両面から、Docker Desktop以外の選択肢も視野に入れることが賢明です。組織全体での導入計画時には、これらの「落とし穴」を事前に認識し、適切な戦略を立てることが求められます。
Podmanとは?デーモンレス・ルートレス設計のメリット
Docker Desktopのライセンス変更を背景に、コンテナ技術の代替ツールとして注目を集めているのがPodmanです。PodmanはRed Hatが主導して開発しているコンテナ管理ツールで、Dockerと高いコマンド互換性を持ちながら、いくつかの決定的な特徴で差別化を図っています。その最大の特長は、「デーモンレス」かつ「ルートレス」設計である点です。
「デーモンレス」とは、Dockerのようにコンテナを管理する中央デーモン(dockerd)を必要としないことを意味します。これにより、単一障害点のリスクが低減され、プロセスごとに独立して動作するため、より堅牢でセキュアなコンテナ環境を構築できます。デーモンがクラッシュしても、実行中のコンテナに影響を与えにくいというメリットもあります。一方、「ルートレス」とは、root権限なしでコンテナを実行できることを指します。これにより、コンテナ内部で権限昇格があったとしても、ホストシステムへの影響を最小限に抑えることができ、セキュリティリスクが大幅に低減されます。
Podmanは、OCI(Open Container Initiative)に準拠しており、Dockerイメージをそのまま利用できます。Docker CLIとほぼ同じコマンド体系を持っているため、既存のDockerユーザーであれば、学習コストを抑えて容易に移行できるでしょう。特にセキュリティを重視する企業や、複数のコンテナを独立して管理したい開発者にとって、Podmanは魅力的な選択肢となります。Linux環境ではネイティブに利用でき、macOSやWindowsでもWSL 2を介して利用が可能です。
Podmanの「デーモンレス」と「ルートレス」設計は、特にセキュリティを重視する環境や、システム全体への影響を最小限に抑えたい場合に大きなメリットをもたらします。これにより、Docker Desktopのライセンスやセキュリティ懸念から代替ツールを検討する際の有力な選択肢となり得ます。
Dockerからの移行検討とスキルギャップへの対応
Docker Desktopのライセンス変更やPodmanのような代替ツールの登場により、既存のDocker環境から他のコンテナツールへの移行を検討する企業も増えています。Podmanへの移行は、高いコマンド互換性があるため比較的スムーズに進む可能性が高いですが、それでも考慮すべき点がいくつかあります。例えば、Docker Composeの代替としてPodman Compose(またはPodman Quadlet)を利用することになりますが、一部コマンドの差異や機能の有無を確認しておく必要があります。また、CI/CDパイプラインやコンテナオーケストレーションツールとの連携についても、事前に動作検証を行うことが重要です。
こうした技術革新に伴い、エンジニアに求められるスキルも常に変化しています。経済産業省/IPAが提言する「デジタルスキル標準」にある通り、Docker単体だけでなく、クラウド技術、CI/CD、コンテナオーケストレーション(Kubernetesなど)を含めた体系的な学習が推奨されます。新しいツールへの移行は、単なる技術的な変更だけでなく、チーム全体のスキルアップの機会と捉えることができます。
スキルギャップへの対応としては、社内での勉強会の実施、外部研修の活用、オンライン学習プラットフォームの導入などが有効です。特に、Podmanのような新しいツールに関しては、公式ドキュメントやコミュニティ情報を活用しながら、実践的な経験を積むことが重要です。コンテナ技術を取り巻くエコシステムは常に進化しており、継続的な学習と情報収集が安定した運用と生産性向上に繋がります。
出典:Red Hat、経済産業省 / IPA
【ケース】導入環境のミスマッチを回避し安定運用を実現した例
架空のケース:導入前の混乱と課題認識
とある中堅システム開発企業「株式会社テックソリューションズ」では、以前から開発環境の構築に多くの時間を要していました。複数のプロジェクトが並行し、それぞれが異なるプログラミング言語(Node.js、Python、Javaなど)やデータベース(MySQL、PostgreSQL、MongoDB)を使用していたため、各開発者のローカル環境は常にバージョン競合や依存関係の問題を抱えていました。新しい開発者が参画するたびに、環境構築に数日かかることも珍しくなく、本来の業務であるコーディングに着手するまでに多大なロスが発生していました。
さらに、テスト環境と開発環境、本番環境の間で微妙な差異が生じ、開発段階では発生しなかったバグがテスト段階で顕在化したり、本番デプロイ後に初めて問題が発覚するといった事態も頻発していました。これらの問題は、プロジェクトの遅延や品質低下に直結し、技術負債として蓄積されていました。特に、Docker Desktopのライセンス変更が発表された際、無償利用できる範囲とそうでない範囲の認識がチーム内で曖昧であったため、一部のプロジェクトではすでにライセンス違反のリスクを抱えている状況も確認されました。
このような状況を鑑み、CTOは開発効率の抜本的な改善とコンプライアンス遵守のため、コンテナ技術の本格導入を決定しました。しかし、Docker一辺倒ではなく、自社の開発体制、セキュリティ要件、将来的な拡張性を考慮した上での最適なツール選定が課題として浮上しました。
課題解決のための具体的な行動と施策
株式会社テックソリューションズは、導入前の混乱と課題を解決するため、以下の具体的な行動と施策を実行しました。まず、コンテナ技術導入プロジェクトを発足させ、主要な開発リードとインフラ担当者が参加する横断的なチームを編成しました。このチームは、現状の開発環境の問題点を詳細に洗い出し、DockerとPodmanの比較検証を行うPoC(概念実証)を実施しました。
PoCでは、両ツールのインストール手順、既存プロジェクトのコンテナ化、パフォーマンス、コマンド互換性、そしてセキュリティ面での違いを多角的に評価しました。特に、Docker Desktopのライセンス問題を回避するため、商用利用におけるコストと、オープンソースであるPodmanのメリット・デメリットを深く掘り下げて検討しました。その結果、セキュリティ要件が高く、将来的に大規模なマイクロサービス展開を見据えている点から、Podmanを主要なコンテナランタイムとして採用する方向性を定めました。
同時に、全開発者を対象としたDocker/Podmanの基礎研修を企画・実施しました。この研修では、コンテナの概念、Dockerfileの書き方、Docker Compose(またはPodman Compose)の利用方法、そしてコンテナ利用時のセキュリティベストプラクティスを網羅的に学習しました。また、プロジェクトごとに既存アプリケーションのコンテナ化を順次進め、CI/CDパイプラインとの連携も強化しました。ライセンスの確認漏れを避けるため、IT資産管理部署と連携し、今後導入する全てのソフトウェアに対してライセンス事前確認フローを義務付けました。
導入後の効果と安定運用に向けた継続的な取り組み
株式会社テックソリューションズのコンテナ技術導入は、期待以上の効果をもたらしました。まず、開発環境の構築時間が平均で70%削減され、新しい開発者がプロジェクトに合流してから実際に開発を始めるまでの期間が大幅に短縮されました。これにより、プロジェクト全体の生産性が向上し、メンバーはより創造的な業務に集中できるようになりました。
次に、開発・テスト・本番環境の一貫性が確保されたことで、環境差異に起因するバグが激減し、ソフトウェアの品質が向上しました。特に、Podmanのルートレスモードによるコンテナ実行は、セキュリティチームからも高い評価を受け、本番環境へのデプロイにおける信頼性が向上しました。これにより、デプロイ頻度が増加し、より迅速な機能改善やバグ修正が可能になりました。また、Docker Desktopのライセンス問題もPodmanへの移行により回避され、コンプライアンスリスクが解消されました。
安定運用に向けた継続的な取り組みとして、同社は定期的な技術共有会を開催し、最新のコンテナ技術やベストプラクティスに関する情報をアップデートし続けています。セキュリティ対策も強化し、コンテナイメージの脆弱性スキャンをCI/CDパイプラインに組み込み、潜在的なリスクを早期に発見・対処する体制を構築しました。また、コンテナのログ管理や監視についても、専用のツールを導入し、障害発生時の迅速な対応と原因特定ができるよう改善を進めています。この一連の取り組みにより、株式会社テックソリューションズは、変化の速いIT業界で競争力を維持するための強固な基盤を築くことができました。
- Docker導入前にライセンス規定を正しく理解できていますか?
- 開発チーム内でDocker/コンテナの基本知識は共有されていますか?
- 代替ツール(Podmanなど)の検討を行いましたか?
- 既存プロジェクトのコンテナ化計画は立っていますか?
- CI/CDパイプラインとの連携を考慮に入れていますか?
- セキュリティ対策(脆弱性スキャン、ルートレス実行など)を計画していますか?
- 導入後の継続的な学習・スキルアップの機会を設けていますか?
まとめ
よくある質問
Q: Dockerはどこからダウンロードできますか?
A: Docker公式ウェブサイトからダウンロードできます。Windows、macOS向けにはDocker Desktop、Linux向けにはパッケージマネージャー経由でのインストールが推奨されます。
Q: Dockerの導入に特別なスキルは必要ですか?
A: 基本的なOS操作スキルがあれば導入は可能です。公式ドキュメントや本記事の手順に沿って進めれば、初心者でも比較的容易に環境構築ができます。
Q: Dockerで具体的にどのようなことができますか?
A: 開発環境の統一、アプリケーションの分離・ポータビリティ確保、CI/CDパイプラインの効率化などが可能です。コンテナ技術により、開発から本番環境まで一貫した運用を実現します。
Q: Dockerの代替となるツールはありますか?
A: はい、Podmanが有力な代替ツールとして挙げられます。特にrootless環境での運用や、より軽量なコンテナ実行を求める場合に検討する価値があります。
Q: Dockerを利用する上でのデメリットは何ですか?
A: 運用にはリソース消費や学習コストが発生します。また、セキュリティ設定の複雑さや、コンテナイメージの管理が煩雑になる可能性も考慮が必要です。
