個人開発・サービス運用をわかりやすく解説

個人開発の運用コストは、サービスを公開した後ではなく、設計段階の意思決定で大部分が決まる。どこまでを静的ファイルにできるか。データをどこに置くか。決済や認証を自前で持つのか、外部サービスに委ねるのか。この判断を曖昧にしたまま実装を進めると、後から構成を変更するたびに費用と保守負荷が膨らむ。

本稿では、インフラ維持費を実質0円に抑える静的ホスティングの考え方から、独自ドメインや外部APIの固定費、GitHub Actionsによるビルド・デプロイの自動化、決済機能に関わる法規制、そしてLaravel・Docker・WordPressを含む長期運用の設計までを整理する。

インフラ維持費を実質0円に抑える静的ホスティング戦略

個人開発のサービス運用で最初に検討すべきなのは、サーバーサイド処理をどこまで省けるかである。フロントエンドだけで完結する構成にできれば、サーバーを常時稼働させる費用は不要になる。ホスティングサービスの無料枠を使える範囲なら、インフラ維持費は独自ドメインの費用だけに抑えられる。

ブログ、ポートフォリオ、製品紹介ページ、ドキュメントサイト、予約フォームの一部などは、静的ファイルで十分に成立する。毎回サーバー側でHTMLを生成する必要がなければ、ビルド時にページを作り、生成物を配信すればよい。

代表的な選択肢を比較すると、次のようになる。

無料枠の上限だけを比べて、最も数字が大きいサービスを選べばよいわけではない。重要なのは、自分の構成がそのサービスの無料枠に収まるかどうかである。

たとえば、記事を更新するたびにビルドするブログと、利用者の操作ごとにサーバーレス関数を実行するサービスでは、確認すべき項目が異なる。前者ではビルド時間とデプロイ回数が重要になり、後者では関数の呼び出し回数や実行時間、データ転送量が問題になる。

Cloudflare PagesやGitHub Pagesのような静的ホスティングは、個人開発の小規模サイトと相性がよい。SSLも標準で利用でき、独自ドメインを設定しても、証明書の発行や更新を毎回手作業で行う必要はない。アクセスが少ない段階では、無料枠の範囲を意識しすぎるよりも、構成を単純に保つことの方が効果が大きい。

サーバーサイド処理をフロントエンドから切り離せるほど、個人開発の固定費と保守箇所は減る。無料サービスを探す前に、そもそも常時稼働するサーバーが必要かを考えたい。

静的サイトにできる範囲を見極める

AstroやNext.jsの静的エクスポート機能を使えば、複数ページのサイトや動的ルーティングを含む構成でも、ビルド時にHTMLを生成して配信できる。更新頻度が低いコンテンツであれば、リクエストのたびにデータベースへアクセスするより、公開時に生成した方が高速で、障害箇所も少ない。

ヘッドレスCMSを組み合わせる場合も同じ考え方が使える。編集者がCMSに記事を登録し、公開を契機にビルドを実行する。閲覧者には生成済みのファイルを返すため、サイト全体を動的なCMSサーバーに置く必要がなくなる。

一方で、次のような機能は静的ファイルだけでは完結しにくい。

• ユーザー登録やログイン状態の管理
• 利用者ごとに異なるデータの表示
• データベースへの書き込み
• 決済結果に応じた権限変更
• 管理画面からのリアルタイムなデータ操作
• 外部サービスの認証情報を隠したAPI呼び出し

この場合でも、サービス全体を大きなサーバーアプリケーションにする必要はない。公開ページは静的ホスティングに置き、認証や書き込みだけをサーバーレス関数、外部API、専用のバックエンドに分離する方法がある。

Laravelを使う場合も、最初からすべてをLaravelアプリケーションに詰め込む必要はない。マーケティングページやドキュメントは静的サイトとして配信し、会員機能や管理画面など、状態を持つ部分だけをLaravelに担当させる構成にすればよい。Laravelの強みは、認証、ルーティング、バリデーション、キュー、メール送信などを一貫した考え方で管理できることにある。その強みが必要な範囲に絞って使う方が、個人開発では扱いやすい。

サーバーレスを使うときの注意点

サーバーレス関数は、常時稼働するサーバーを持たずにサーバー側の処理を実行できる。小さなAPIやフォーム送信、Webhookの受け取りには便利だが、何でも置き換えられるわけではない。

関数の実行時間に制限がある場合、長時間の画像処理や大きなファイルの変換には向かない。関数が一時的な実行環境で動く仕組みでは、ローカルファイルを永続的な保存先として使うこともできない。データを保存するなら、オブジェクトストレージやデータベースなど、別の保存先を用意する必要がある。

また、無料枠があることと、将来も無料で使い続けられることは別である。利用量が増えたときにどの項目が課金対象になるのか、無料枠を超えた場合に自動で請求されるのか、上限を設定できるのかは確認しておきたい。

個人開発では、サービスが成長したときの費用より、想定外の利用で請求額が膨らむリスクの方が怖いことがある。API呼び出しの回数制限、ユーザーごとの利用上限、管理者への通知は、サービスの規模に関係なく早めに用意しておくべきである。

独自ドメインと外部API利用時に発生する固定費の考え方

静的ホスティングでインフラ費用を0円に抑えても、すべてのコストが消えるわけではない。個人開発のサービス運用で発生する費用は、固定費、従量課金、決済手数料、開発者向けツールの利用料に分けて考えると整理しやすい。

独自ドメインは小さくても継続する費用

.comドメインの年間維持費用は、レジストラやキャンペーンの有無によって変わるが、一般に1,000円から2,000円程度が目安になる。月額に換算すれば大きな金額ではないものの、サービスを数年運用するなら無視できない固定費である。

ドメインは取得時の価格だけでなく、更新時の価格を見る必要がある。初年度だけ安く、翌年から通常料金に戻るサービスもある。Whois情報の扱い、移管のしやすさ、DNS設定の機能、更新通知の方法も、料金と同じくらい重要だ。

Cloudflare Registrarのように、レジストリへの支払いを基本とする料金体系を採用しているサービスもある。安さだけで決めるのではなく、DNS、メール転送、ドメインロック、移管手続きなどを含めて、自分が管理しやすいサービスを選びたい。

ドメインを複数取得すると、サービス本体の費用が小さくても、検証用、ブランド保護用、短縮URL用と目的が増えるにつれて固定費は積み上がる。個人開発では、使っていないドメインを定期的に整理するだけでも、支出の見直しになる。

外部APIとAIツールは利用者数に比例して増える

外部APIをサービスの機能として組み込む場合、料金はサーバー代のような固定費ではなく、利用量に応じて増えることが多い。翻訳、決済、メール送信、地図、検索、画像処理、生成AIなど、外部サービスに依存するほど、ユーザー数と利用回数をコストに変換して考える必要がある。

開発者が使うツールと、ユーザー向け機能として呼び出すAPIは分けて管理したい。たとえば、開発補助用のAIサブスクリプションは開発者の人数や契約数に応じた固定費だが、AI機能をサービスの中に組み込む場合は、ユーザーの操作回数や入力の長さによって従量課金が発生する。

無料プランでユーザーを増やしても、APIの利用料が収益を上回る可能性はある。特に、1回の操作で複数のAPIを呼ぶ設計や、失敗時に無制限で再試行する設計は、利用者が少ない段階でも費用が予測しにくい。

実装では、次のような制御を入れておくとよい。

• 1ユーザーあたりの1日・1か月の利用回数を制限する
• 同じ入力に対する結果をキャッシュする
• 失敗時の再試行回数と待ち時間を決める
• 管理者だけが確認できる利用量と費用の記録を残す
• 無料プランと有料プランで利用できる処理量を分ける
• 外部APIが停止しても、サービス全体が落ちない代替表示を用意する

費用を計算するときは、「APIの料金」だけでなく、失敗リクエスト、検証用リクエスト、管理画面からの再実行も含めて考える。サービス公開後は、開発時よりも利用パターンが読みにくくなるからである。

レンタルサーバーを選ぶ場面

サーバーサイド処理が必要で、サーバーレスでは対応しきれない場合、共用レンタルサーバーは依然として有力な選択肢である。月額500円から1,500円程度のプランでも、PHP、データベース、メール、管理画面をまとめて利用できる。

WordPressを使うブログや小規模なメディアであれば、共用サーバーにWordPressを置く構成は現在も現実的である。問題は、WordPressが動くことではなく、更新とバックアップを誰が担当するかだ。テーマやプラグインを増やすほど、互換性の確認や脆弱性対応が必要になる。

Laravelアプリケーションを共用サーバーで運用する場合は、PHPのバージョン、デプロイ方法、キューの実行、定期処理、書き込み権限などを確認する必要がある。静的サイトと比べると、設定項目が増えるため、単純に月額料金だけで比較すると判断を誤る。

Dockerを使ってローカル開発環境を揃えていても、公開先がDockerに対応しているとは限らない。開発環境の再現性を高めるDockerと、本番環境の運用コストは別の問題として考えるべきである。

個人開発のコスト構造は「ドメイン代に何が加わるか」で考えると見通しがよい。無料枠を探すより、費用が増える条件を先に把握した方が、後の判断は速くなる。

GitHub Actionsによるビルド・デプロイの自動化設計

個人開発の運用負荷を削減するうえで、効果が大きいのはCI/CDパイプラインの構築である。GitHub Actionsを使えば、リポジトリへの変更をきっかけに、テスト、ビルド、デプロイ、定期処理を自動実行できる。

手動デプロイは、最初の数回なら問題にならない。しかし、修正のたびに本番サーバーへ接続し、ファイルをアップロードし、キャッシュを削除し、表示を確認する作業を続けると、時間だけでなくミスの可能性が積み上がる。どの変更が本番に反映されたのか分からなくなることもある。

基本的な流れは、次のように分けると扱いやすい。

1. 開発用ブランチで変更を作成する

2. プルリクエストを作り、自動テストを実行する

3. レビューまたは自分自身の確認を通過させる

4. mainブランチへの反映を契機に本番ビルドを行う

5. ビルド成果物を静的ホスティングやサーバーへ配信する

6. デプロイ後のURLとヘルスチェックを確認する

静的サイトの場合は、依存関係をクリーンインストールし、ビルドを実行し、生成されたdistなどのディレクトリを配信する。Laravelの場合は、依存関係のインストール、設定ファイルの反映、キャッシュの再構築、データベース更新の扱いまで含めて設計する必要がある。

WordPressでは、データベースとアップロードされたメディアをどう扱うかが問題になる。テーマやプラグインのファイルだけをGitで管理し、記事データや画像は別途バックアップする構成もある。公開環境のデータベースを自動で上書きするような仕組みは、個人開発でも慎重に設計しなければならない。

本番デプロイと検証用環境を分ける

mainブランチへのpushですぐ本番に反映する構成は、静的な個人ブログなら十分に機能する。一方、決済、会員情報、Laravelのデータベース更新などを含むサービスでは、検証用環境を一つ用意した方が安全である。

本番と検証用で分ける項目は、アプリケーションのURLだけではない。

• データベースの接続先
• 外部APIの認証情報
• 決済サービスのテスト環境と本番環境
• メールの送信先
• ファイルストレージ
• ログの保存先
• 管理者権限
• Webhookの受信URL

特に決済とメールは、検証用のつもりで本物の顧客や利用者に通知が送られる事故が起こりやすい。環境変数を分離し、秘密情報をリポジトリに直接書かず、テスト環境では送信先を制限する。

GitHub Actionsのシークレット機能は、APIトークンやデプロイキーを保管するために使える。ただし、シークレットに入れたから安全というわけではない。ログに環境変数を出力しないこと、権限を必要最小限にすること、使わなくなったキーを削除することが重要である。

定期バッチ処理を自動化する

スケジュール実行を使えば、定期処理も自動化できる。個人開発で使いやすい例は次の通りだ。

• サイトマップの再生成とデプロイ
• 外部APIから取得したデータのキャッシュ更新
• サイト内リンクの検査
• 依存関係のセキュリティ監査
• バックアップの実行結果の確認
• 期限切れデータや一時ファイルの削除
• 利用量とAPI費用の集計

ただし、定期処理を増やすほど、失敗時の通知が重要になる。毎週実行されるはずのバッチが静かに失敗しても、誰も気づかなければ自動化の意味がない。処理の成否をGitHub Issues、メール、チャット通知などで確認できるようにする。

自動化の目的は、作業を人間から完全に奪うことではない。人間が毎回同じ操作を繰り返さなくても済むようにし、判断が必要な場面だけ通知することにある。

決済機能導入における法規制と実装のハードル

サービスにマネタイズを組み込む場合、決済機能の導入は避けて通れない。しかし、個人開発者が決済機能を実装するには、画面を作り、決済ボタンを設置するだけでは足りない。本人確認、返金、利用規約、特定商取引法に基づく表示、個人情報の取り扱い、売上の受け渡しなどを考える必要がある。

ここでは法的な最終判断を扱うのではなく、設計時に見落としやすい論点を整理する。サービスの形態や提供地域によって適用されるルールは変わるため、第三者間取引や資金移動を扱う場合は、専門家や決済事業者への確認が必要になる。

Stripeを直接導入する場合

Stripeは個人開発者でも導入しやすい決済プラットフォームだが、導入すれば法的な責任がすべてなくなるわけではない。

まず、アカウント開設時に本人確認が行われる。事業内容、販売する商品やサービス、売上の受取人、返金方針などの情報が必要になることがある。サービスの説明が曖昧だと、審査や利用開始までに時間がかかる可能性がある。

自分が提供するサービスの料金を受け取るだけなら、第三者間取引を仲介するサービスより構造は単純になる。一方、プラットフォーム上で複数の出品者から利用者へ商品やサービスを提供し、売上を出品者へ分配する場合は、資金決済や送金に関わる論点が増える。

技術的にも、次の処理が必要になる。

• 決済開始前に注文内容と金額を確定する
• 決済完了画面だけでなくWebhookで支払い状態を確認する
• 二重決済や二重付与を防ぐ
• 返金・キャンセル・期限切れを処理する
• 支払い済みのユーザーだけに機能を開放する
• 決済サービス側の障害時に状態が不整合にならないようにする
• 管理者が注文と決済の状態を追跡できるようにする

Laravelをバックエンドに使うなら、決済サービスから届くWebhookを受け取り、署名を検証したうえで注文状態を更新する設計にする。ブラウザから戻ってきたという事実だけで、支払い完了と判断してはいけない。利用者が決済後に画面を閉じた場合でも、サーバー側で正しい状態を記録できるようにする必要がある。

外部プラットフォームに委託する

初期段階では、決済を外部プラットフォームに委託する方が合理的な場合も多い。デジタルコンテンツや小規模な商品販売であれば、販売ページ、決済、購入後の案内をまとめて提供するサービスを利用できる。

外部プラットフォームを使うと、手数料は発生する。しかし、決済の実装、カード情報の取り扱い、購入メール、返金処理などを自分で抱えずに済む。売上がまだ小さい段階では、手数料を開発時間の代わりに支払うという考え方もできる。

反対に、サービスの中心が継続課金や高度な権限管理である場合、外部販売ページだけでは体験が分断される。ユーザー登録、決済、請求状態、解約、利用権限を一つのサービスとして管理したいなら、いずれ自前のバックエンドが必要になる可能性が高い。

重要なのは、最初から最終形を実装することではない。売れるかどうか分からない段階では、手数料込みでも販売できる形を先に作り、需要が確認できてから決済の内製化を検討する方が、個人開発の資金と時間を守りやすい。

Laravel、Docker、WordPressを長期運用に組み込む

個人開発の技術ブログやサービス運用では、複数の技術を使い分ける場面が多い。Laravelは会員機能や業務ロジック、Dockerは開発環境の再現性、WordPressは更新しやすいコンテンツ管理というように、役割を分けて考えると構成が見えやすくなる。

Laravelは状態を持つ部分に集中させる

Laravelを採用する理由は、単にPHPで書けるからではない。認証、フォーム処理、データベース、メール、キュー、管理画面など、サービス運用に必要な要素を一つの枠組みで整理できるからである。

ただし、Laravelで作ったアプリケーションを常時稼働させるには、PHPの実行環境、データベース、ストレージ、定期処理、ログ管理が必要になる。静的ページまでLaravelで毎回生成する構成にすると、アクセスが少ない段階でも必要以上の運用対象を抱えることになる。

サービスのトップページや料金説明、ヘルプ、利用規約などは静的にし、ログイン後のダッシュボードやデータ操作だけをLaravelに任せる構成は有効だ。フロントエンドとバックエンドを分離することで、公開ページの配信負荷とアプリケーションの処理負荷を切り分けられる。

Dockerは「本番を安くする道具」ではない

Dockerは、開発者の環境差を小さくするための道具として非常に便利である。PHPのバージョン、データベース、キャッシュサーバー、メールテスト用のサービスなどをコンテナにまとめれば、開発者のパソコンに直接依存しにくい。

Laravelの開発では、Docker Composeを使ってアプリケーション、データベース、キュー処理をまとめる構成がよく採用される。新しく参加した人が環境を作りやすくなり、バージョン違いによる不具合も減らせる。

しかし、Dockerを導入したからといって、本番運用が自動的に簡単になるわけではない。本番では、イメージの更新、脆弱性スキャン、ログの保存、ボリュームのバックアップ、コンテナの再起動、秘密情報の管理が必要になる。

個人開発で大切なのは、Dockerを使う目的を明確にすることだ。ローカル環境の再現性が目的なら、まず開発環境に絞って使えばよい。本番までコンテナ化する場合は、ホスティング先の更新方法と障害時の復旧手順まで確認してから採用する。

WordPressは更新を止めない仕組みが必要

WordPressは、記事の追加や編集を非エンジニアでも行いやすい。一方で、WordPress本体、テーマ、プラグイン、PHP、データベースという複数の要素が組み合わさるため、更新を放置すると脆弱性や互換性の問題が発生する。

最低限、次の運用は必要になる。

• WordPress本体とプラグインの更新状況を確認する
• 更新前にデータベースとメディアをバックアップする
• 使っていないテーマとプラグインを削除する
• 管理者アカウントを必要以上に増やさない
• ログイン画面への不正アクセスを監視する
• 更新後にトップページ、記事、フォームを確認する
• バックアップから復元できることを定期的に確認する

自動更新は便利だが、すべてを無条件に自動更新すればよいわけではない。重要なプラグインの大幅な更新では、検証用サイトで表示やフォームを確認してから本番へ反映する方が安全である。

WordPressをコンテンツ管理に使い、フロントエンドを静的サイトとして配信するヘッドレス構成もある。この場合、WordPress本体を公開画面の配信から切り離せるため、閲覧側の負荷を抑えやすい。ただし、APIの公開範囲、認証、更新時のビルド、画像の扱いなど、通常のWordPressとは別の設計が必要になる。

長期運用を見据えたメンテナンス負荷の削減手法

サービスを公開した後、個人開発者が直面する最大の課題は継続的なメンテナンスである。フレームワークのセキュリティ更新、依存パッケージのバージョン管理、ドメインの更新、バックアップ、障害監視。これらは一度設定すれば終わるものではない。

運用の設計で大事なのは、作業をなくすことではなく、忘れても事故になりにくい状態を作ることである。

依存関係の更新を管理する

DependabotやRenovateを使えば、依存パッケージの脆弱性修正や更新をプルリクエストとして受け取れる。更新を自動でマージするかどうかは、サービスの性質によって判断したい。

表示だけを行う静的サイトであれば、小さな更新を自動で取り込んでも影響は限定的かもしれない。一方、決済やユーザー情報を扱うLaravelアプリケーションでは、更新によって認証や入力処理が変わる可能性がある。テストを通し、変更内容を確認してから適用する方がよい。

WordPressでは、プラグインの数そのものを減らすことが最大の負荷削減になる。似た機能を持つプラグインを複数入れたり、短期的な要件のために使い終わったプラグインを残したりすると、更新対象と脆弱性の入口が増える。

SSL、ドメイン、秘密情報を一か所で管理しない

Let's Encryptの証明書は一定期間で更新が必要になる。CloudflareやNetlifyなど、プラットフォーム側でSSL管理が完結するサービスを使えば、証明書更新を手動で行う場面は減る。

一方、独自サーバーやDocker環境で証明書を管理する場合は、自動更新の設定と更新後の反映を確認する必要がある。証明書の更新処理が動いていても、Webサーバーが古い証明書を使い続けることはある。更新の成否だけでなく、実際の公開URLが新しい証明書を返しているかまで確認したい。

ドメインの更新も同じである。自動更新を有効にし、登録メールアドレスを放置しない。ドメイン管理用のアカウントには多要素認証を設定し、決済情報を更新できる人を限定する。

APIキーやデータベースのパスワードは、ソースコードやDockerの設定ファイルに直接書かない。開発用、検証用、本番用で分け、不要になったキーは無効化する。個人開発では管理者が一人になりやすいからこそ、将来引き継ぐときに困らない場所へ情報を整理しておく必要がある。

監視とバックアップは役割が違う

UptimeRobotやBetter Uptimeなどの無料プランを使えば、公開URLの応答を定期的に確認し、停止時にメール通知を受け取れる。これは障害を早く知るための仕組みであり、障害を防ぐ仕組みではない。

バックアップは、データを失ったときに戻すための仕組みである。監視が正常でも、誤操作による削除、プラグインの更新失敗、データベースの破損は起こり得る。

バックアップでは、次の点を決めておきたい。

• 何を保存するか
• どの頻度で取得するか
• どの期間まで残すか
• 本番環境とは別の場所に保管するか
• 復元手順を誰が実行するか
• 復元できたことをどう確認するか

WordPressなら、記事や固定ページなどのデータベースだけでなく、画像やアップロードファイルも必要になる。Laravelでも、データベースとユーザーがアップロードしたファイルを別々に扱っているなら、両方をバックアップしなければ復旧できない。

自動化するものと判断するものを分ける

長期運用で重要なのは、すべてのメンテナンスタスクを自動化することではない。自動化すべきタスクと、人的判断が必要なタスクを明確に分離することである。

ビルド、テスト、デプロイ、依存関係の更新通知、バックアップ、ヘルスチェックは自動化しやすい。対して、脆弱性修正を本番へ適用するか、古い機能を終了するか、料金を変更するか、障害の影響を利用者へ通知するかは、人間が判断する領域である。

この線引きができていないと、自動化の導入自体が運用負荷になる。毎日大量の通知が届き、すべてを確認しなければならない状態は、手作業より少し効率が悪いだけで、運用が軽くなったとは言えない。

自動化の完成形は、人間が何もしない状態ではない。人間が確認すべき判断だけに集中できる状態である。

個人開発を継続できる構成にする

個人開発のサービス運用コストは、次のように分けて考えると見通しがよい。

• 無料枠で維持しやすいもの — 静的ホスティング、GitHub Actions、基本的な監視
• 継続して発生する固定費 — 独自ドメイン、開発補助ツール、レンタルサーバー
• 利用量に応じて増える費用 — 外部API、AI機能、データ転送、ストレージ
• 売上に応じて発生する費用 — 決済手数料、販売プラットフォームの手数料
• 見落としやすい運用コスト — 障害対応、バックアップ確認、更新作業、問い合わせ対応

設計段階では、まずサーバーサイド処理をどこまで省けるかを決める。静的ホスティングで公開できる部分は静的にし、必要なAPIだけをサーバーレス関数やLaravelに分ける。WordPressを使う場合は、更新とバックアップを含めた運用方法を先に決める。Dockerを使う場合は、ローカル環境の再現性と本番環境の管理を混同しない。

そのうえで、ユーザー1人あたりに発生する費用を考える。外部APIを使うなら、無料ユーザーが増えたときに赤字にならないかを確認する。決済を導入するなら、手数料を差し引いた後の売上で、サーバー費用やAPI費用をまかなえるかを見る。

インフラを安くすること自体が目的になると、必要な機能まで削ってしまう。逆に、最初から高機能なクラウド構成を選ぶと、利用者が増える前に運用が複雑になる。個人開発に向いているのは、安く始められて、必要になった箇所だけを段階的に拡張できる構成である。

静的サイト、外部API、Laravel、Docker、WordPress。これらは競合する選択肢ではなく、役割の違う道具だ。公開ページは静的に、状態を持つ処理はLaravelに、開発環境はDockerで揃え、更新型のコンテンツはWordPressで管理する。すべてを一つの仕組みに押し込めないことが、長期運用では効いてくる。

個人開発のサービスは、公開した瞬間よりも、数か月後に差が出る。毎回の手動作業が残っているか、障害に気づけるか、更新を安全に適用できるか、費用の増え方を把握できているか。インフラ費用を実質0円に抑える工夫も、GitHub Actionsの自動化も、最終的にはこの差を小さくするための手段である。

サービスを続けるために必要なのは、最も新しい技術を一通り採用することではない。自分一人で理解でき、壊れたときに戻せて、利用者が増えたときに費用の構造を説明できること。その条件を満たす小さな構成から始める方が、個人開発の現実には合っている。