ホスティングの管理は、たいてい開発を中断させます。エディタでコードを書き、ホスティングダッシュボードを開いてサイトを作成し、ターミナルに切り替えてプロジェクトをパッケージ化またはプッシュし、ダッシュボードに戻ってデプロイを確認し、DNS、ログ、サーバーリソースに対応が必要になればさらに別のツールを開くことになります。

Hostinger Connector は、このコンテキスト切り替えを減らします。MCP（Model Context Protocol）を通じて Hostinger のサービスを AI コーディングツールに接続し、エディタから離れることなく、AI アシスタントに対応ホスティングリソースの確認や管理を依頼できるようにします。

それは便利そうです。しかし、もっと重要な疑問も浮かびます。AI アシスタントを信頼して、実際のホスティング作業を正確に実行させられるのでしょうか？

それを確かめるために、VS Code と GitHub Copilot で Hostinger Connector を実際の Hostinger アカウントに対してテストしました。小さな Express.js アプリケーション PulseWatch を使い、インストールから本番デプロイまでのワークフローに従いました。さらに、繰り返しのデプロイ、ビルド記録、ログ、そしてアプリケーションの start コマンドをわざと壊した後の復旧もテストしました。

Hostinger Connector Plans with Hostinger

Integrate Hostinger with the apps and services you already use to automate tasks, improve workflows, and manage your website more efficiently.

Hostinger を訪問する

Hostinger Connector の長所と短所

評価の内訳

ここでは、Hostinger Connector を使うかどうかを判断する開発者にとって重要な項目、つまりコスト、機能の幅、日々の使いやすさ、実際のタスクをどれだけ正確に実行できるか、そして問題が起きたときのサポートをどのように採点したかを示します。各スコアは、マーケティングページではなく、実際のテストで分かったことに基づいています。

Hostinger Connector のプランと価格

Hostinger Connector は単体製品として販売されていません。Hostinger によれば Connector はすべてのプランに無料で含まれているため、ホスティング料金に Connector 用の月額費用が別途上乗せされることはありません。

ただし、「無料」には文脈が必要です。Connector は Hostinger リソースを管理しますが、それらを置き換えるものではありません。実行したい作業に必要な対象として、有効なホスティング、クラウド、VPS、ドメイン、メール、その他の Hostinger サービスが依然として必要です。

このレビュー時点では、Connector のランディングページでは Business Web Hosting と Cloud Startup が強調されていました。

価格は適用前の税抜きで表示されていました。プロモーション価格や更新料金は変更されることがあるため、広告上の月額表示だけでプランを判断するのではなく、実際のチェックアウト合計額を確認してください。

価格に関するポイント: Connector を使うためだけに上位プランを購入しないでください。必要な Web サイト数や Web アプリ数、それらに必要なリソース、求めるサポートレベルに基づいてプランを選ぶべきです。Connector は管理レイヤーとして付属しているものであり、価格の主役ではありません。

Hostinger は、対象となるホスティング購入に対して 30 日間の返金保証を案内しています。Connector には単体料金がないため、別個の返金ポリシーを評価する必要はありません。

Hostinger Connector Plans with Hostinger

Integrate Hostinger with the apps and services you already use to automate tasks, improve workflows, and manage your website more efficiently.

Hostinger を訪問する

機能

• Node.js アプリケーションのデプロイ
• PHP と HTML のデプロイ
• WordPress サイト管理
• Website Builder と Horizons のワークフロー
• GitHub 連携デプロイ
• ドメイン接続と整理
• DNS の確認と更新
• SSL とサイト診断
• データベース管理
• VPS のセットアップと管理
• Docker プロジェクトのデプロイ
• CPU とメモリの監視
• 帯域幅とディスクの確認
• サービスとコンテナの再起動
• マルウェアスキャン
• バックアップの復元
• メールキャンペーンの設定
• デプロイとビルドの確認

利用可能な正確なアクションは、アカウント内の Hostinger サービスと、接続した AI クライアントに公開されているツールによって異なります。

Hostinger はレート制限も文書化しています。Connector FAQ によると、デフォルトの上限は 1 分あたり 60 リクエスト、1 時間あたり 1,000 リクエストで、レート制限情報はレスポンスヘッダーで返されます。

これらの制限は対話的な利用には十分寛大ですが、自動化された、あるいは非常に反復的なワークフローでは、不要な重複呼び出しを避けるべきです。

使いやすさ

1. インストールと認証

Hostinger Connector がデプロイやホスティング管理をきちんと行えるかを判断する前に、そもそも動かすまでに何が必要かを知る必要がありました。

エディタの中にとどまることを前提にしたツールは、設定ファイルの編集や API トークンの生成、何度もの再認証が必要になった瞬間に、その魅力をすぐに失います。このセクションはセットアップだけを扱います。実際のタスク検証はその直後に続きます。

拡張機能のインストール

Hostinger Connector を VS Code Marketplace からインストールしました。検索語 “Hostinger” で最初に表示され、公開元は Hostinger Official と記載されており、最初の試行で 2 分以内にインストールできました。

最後の行には注意が必要です。5 星は強そうに見えますが、レビューが 2 件しかないサンプルでは一般的なユーザー体験についてほとんど分かりません。レビュー本文ではこの数値を重視しないほうがよいでしょう。

ひとつ意外だった前提条件: Hostinger Connector は Hostinger のツールを提供しますが、実際にそれらを呼び出すには、エディタ内で既に動作している AI エージェントが必要です。

拡張機能自体は、単独では何ともやり取りできません。VS Code では、そのエージェントは GitHub Copilot Chat です。VS Code が現在 MCP ツール呼び出しに提供している AI インターフェースがこれだからです。私はすでに Copilot を有効にしていたので、この点で手間はかかりませんでしたが、読者は Connector が背後にある AI エージェント次第でしか使えないことを知っておくべきです。

これがインストールされてサインインしていなければ、接続先はありません。

インストールに必要なかったもの:

• API キー
• hPanel からコピーしたトークン
• MCP 設定ファイルの手動編集
• ローカル保存の認証情報
• カスタムサーバーコマンド

拡張機能自体のインストールは、テスト全体の中でも最もスムーズな部分のひとつでした。実質的な注意点は 1 つだけで、Hostinger は前面に出していませんが、この拡張機能は実際に機能するためにエディタ内の有効な AI エージェントを必要とします。

拡張機能が入ったので、次の疑問は、それを実際のアカウントに接続するのも同じくらい簡単かどうかでした。

アカウントの接続

アカウント接続は “1-Click Connect” ボタンを使った OAuth でした。VS Code はブラウザで Hostinger の認証ページを開き、既存の Hostinger セッションを検出し、hostinger-mcp と表示されたものへのアクセスを承認するよう求めました。

Allow をクリックすると、VS Code に戻り “Connected via OAuth” と表示されました。

認可画面には、Connector が Web サイト、ホスティング、ドメイン、サブスクリプション、その他の Hostinger サービスを管理できると書かれていました。

それはカテゴリの一覧であって、権限を項目ごとに示した内訳ではありませんでした。Web サイトの管理とサブスクリプションの管理は、リスクのレベルがかなり異なるので、ここはもっと細かい表示がほしかったところです。

その点である程度の制御を与えてくれたのは、拡張機能内の別パネルで、各ツールカテゴリを一覧表示し、それぞれを有効または無効にできたことです。

合計は 199 のツールで、そのうち 125 がデフォルトで有効でした。Ecommerce と VPS は、直接テストする準備ができるまでオフのままにし、拡張機能はテスト全体を通してその境界を尊重しました。

これは、Hostinger のマーケティングページには載っていませんが、AI アシスタントにどれだけのアカウントアクセスを与えるかを決める人にとっては重要なセキュリティ上の詳細です。これは本物の強みだと言えます。

同じパネルからアカウントの切断もでき、Hostinger のパスワードを変更したり、保存されたトークンを探したりする必要はありませんでした。

認証は素早く、トークン管理も不要でしたが、権限画面は細かい粒度ではなく大まかな表示です。実際のリスクを制限するうえでは、OAuth 画面よりも、拡張機能内のカテゴリ単位のツール制御のほうが役立ちます。

対応エディタ

Hostinger は、拡張機能のオンボーディング画面から集めた以下のクライアントをサポートしていると案内しています。

私は VS Code と GitHub Copilot を主なテスト環境として使用しました。

セットアップは、Connector が簡単に使い始められることを示してくれました。しかし、それだけでは、接続後に本当に仕事をきちんとこなせるかはまだ分かりません。それが次に取り組んだ、より難しい問いでした。

2. Hostinger Connector の実動テスト

拡張機能のインストールと接続は簡単です。本当に重要なのは、実際のホスティング作業を正しく行えるかどうかです。そこで私は小さな Express.js アプリケーション PulseWatch を作成し、開発者がインストール後にたどるであろうのと同じ道筋、つまりアカウントの確認、デプロイ先の特定、プロジェクトのデプロイ、更新、結果の確認、そして意図的に起こした失敗からの復旧を Connector に試させました。

PulseWatch は意図的にシンプルにしました。Express サーバー、ホームページ、package.json の start スクリプト、そして JSON を返す /api/health エンドポイントだけです。このヘルスエンドポイントは後で重要になりました。

ホスティングプラットフォームは、アプリケーションが起動に失敗していてもビルド完了を報告することがあります。ライブのエンドポイントがあれば、ステータスバッジを信じるのではなく、デプロイされたプロセスが本当に応答しているかどうかを独立して確認できます。

アカウントデータの読み取り

まずは、AI に本番変更を許可する前に、読み取り専用のプロンプトから始めました。アカウントを正確に説明できなければ、デプロイ、DNS、VPS の操作を任せる理由はほとんどありません。

Connector の Web サイト一覧ツールは 5 つのサイトを返しました。

• webhostpro.io
• hostinger-monitor.hostadvice.com
• hostingermonitor.hostadvice.com
• blog.webhostpro.io
• red-lapwing-356282.hostingersite.com

実際のアカウントには、それより多くのサイトがありました。hPanel では Premium、Business、Growth プランにまたがってサイトがあり、WordPress サイト、PHP/HTML サイト、Website Builder プロジェクト、複数の一時ドメインが含まれていました。

有効なホスティングプランについて別のプロンプトを出すと、アシスタントは「1 つのアクティブなホスティングプラン」があると答えました。hPanel には Premium、Growth、Business の 3 つが表示されていました。

Connector に公平を期すと、矛盾を指摘したときには自己修正し、確認できたことと推測したことを明確に分け、誤った主張を繰り返しませんでした。

これは、間違いを押し通すよりはずっと良い失敗の仕方です。ただし、プランに関する質問の最初の答えを鵜呑みにすべきではないことは意味します。

読み取り専用のアクセスは機能しましたが、アカウント全体に関する質問への最初の答えは不完全でした。挑めば修正された点は重要ですが、こちらが挑まなくてもよかったはずです。

アカウントの可視性におけるこのギャップは、より大きな問題の前触れでした。それが実際に意味を持つかどうかは、次に Connector に名前を一度も教えていない Web サイトを探させたときに分かりました。

デプロイ先の検索

ここでのテストが最も多くのことを明らかにしました。私は、最近作成した Node.js サイトを、そのドメイン名を私が言わずに、既存のサイトには触れずに特定するようアシスタントに依頼しました。

ターゲット選択は、本番アカウントに対して作用できるツールにとって基本的な安全要件なので、私はきれいな答えではなく、不確実性への対処を見たかったのです。

実際に起こったことは以下の順番でした。

根本的な問題は、使った 2 つの ID がホスティング注文 ID ではなく、ドメインのリソース ID だったことです。その違いを確認しないまま、実際の Web サイト作成ツールを呼び出してしまいました。

なぜそうなったのかを尋ねると、アシスタントは最終的に正確な説明をしました。利用可能な Web サイト一覧ツールが最初から使えたのに、新しいサイトを hPanel で作成した後に再び呼ばず、未確認のドメインで不足分を埋めてしまったのです。

その一覧ツールを再実行して新しいレコードを確認するよう直接指示すると、代わりに 3 つの無関係なデプロイ関連の検索ツールを呼び出し、「新しい Web サイトは現れなかった」と報告しました。しかし、実際に行ったツール呼び出しだけでは、その結論は支えられませんでした。

これらの失敗でアカウントに余計なサイトが作られることはありませんでした。失敗した呼び出しは何も残しませんでした。しかし、このパターンははっきり指摘する価値があります。不完全なデータに対して、アシスタントはもっともらしい推測で穴埋めし、弱いシグナルを強い証拠のように扱い、その推測が確認される前に本番アカウントに対して行動したのです。

これがこのセクションで最も重要な発見です。Connector はターゲットを推測して、その推測に基づいて行動し、立ち止まって確認を求めることはありません。ここでは安全に失敗しましたが、弱いシグナルを証拠として扱う癖には、自分のアカウントでも注意すべきです。

Connector が単独でターゲットを見つけられなかったので、次の選択肢は自分でターゲットを作ることでした。そこで、これが何かを変えるのか確認することにしました。

hPanel でのセットアップ完了

Connector が新しいターゲットを自力で確実に見つけられなかったので、Hostinger が Connector ベースのデプロイの前に何を準備するのかを見るため、hPanel で手動の初期設定を完了しました。

手順は次の通りでした。新しいサイトを作成 → Node.js Web app → 一時ドメイン → Hostinger が自動でイギリスのデータセンターを選択し、推定レイテンシー 147ms を表示 → 3 種類のデプロイ方法から選択。

この 3 画面目は、それ自体で注意すべきです。Hostinger は、「Build with Hostinger Connector」を、GitHub インポートや手動ファイルアップロードと並ぶデプロイ方法として提供しています。私は、これでサイトのセットアップが完了するものと期待して選びました。

ところが、すでに完了していた Connector のインストールページへリダイレクトされただけでした。これは本当のオンボーディングの不備です。Connector ネイティブの経路として示された選択肢が、実際には何もプロビジョニングしませんでした。

そこで戻って、代わりに手動ファイルアップロードを選びました。Hostinger は私のプロジェクトアーカイブ（11.46 KB、node_modules を除外）を受け入れ、設定画面では正確な自動検出が表示されました。

• フレームワークプリセット: Express
• Node バージョン: 22.x
• ルートディレクトリ: ./

Deploy をクリックすると、デプロイは成功し、Hostinger は本物の一時ドメイン orange-walrus-700988.hostingersite.com を割り当てました。これは Connector が先ほど作り出したドメインとは別のものです。私はホームページと /api/health を手動で開き、どちらも動作することを確認しました。

Connector が見つけるのを待つのをやめると、手動の経路は摩擦なく機能しました。この画面の「Build with Hostinger Connector」ボタンは修正するか削除すべきです。現状では、実際には行わないことを約束しています。

本物で確認済みの Web サイトができました。次の疑問は、Connector が、実体のある対象を見つけられるようになった後で、振る舞いを変えるかどうかでした。

ライブアプリケーションのデプロイと更新

実際に確認済みの Web サイトができたので、Connector にその正確なドメインを確認させました。今回はきちんと機能しました。

これで重要なことが確認できました。先ほどの失敗は、新しいターゲットの特定と作成に関するものであって、既存の Node.js サイトを扱う能力そのものの問題ではなかったのです。

次に、Hostinger が最も強く宣伝している機能、つまりコードをローカルで変更し、hPanel を開かずに公開する機能を試しました。

私はアシスタントに、ホームページの文言を “Monitor Every Service. Catch Every Issue.” から “Monitor Every Service. Resolve Issues Faster.” に変更するよう依頼しました。

全体の更新には約 1 分かかりました。アシスタントは送信直後には新しいデプロイを “pending” と報告しましたが、それは Hostinger の処理がまだ終わっていなかったからです。

私が自分でライブサイトを更新すると、新しい見出しはすでに表示されていました。

後で取得したビルドログは具体的で役に立ちました。67 パッケージが追加され、68 件が監査され、脆弱性はゼロ、エラーもありませんでした。

既に存在するサイトに対しては、これは Hostinger が約束するワークフローにかなり近いものです。編集し、ローカルで確認し、公開し、検証する。しかもエディタから離れずに、約 1 分で完了します。これは全テストの中で最も強い結果でした。

きれいなデプロイだけでは、順調な流れが機能することしか分かりません。プレッシャーがかかったとき Connector が何をするのかを知るため、今度はわざとアプリケーションを壊しました。

障害復旧のテスト

本当に信頼に値するのは、きれいなデモではなく、実際の失敗に直面したときです。Connector のステータス報告とログが本当に診断に役立つかを見るため、私は意図的にアプリケーションを壊しました。

変更前に、アシスタントは package.json を package.json.bak としてバックアップしました。これはそれ自体で良い習慣です。

次に start スクリプトを “start”: “node server.js” から “start”: “node missing-server.js” に変更させました。これは存在しないファイルです。

ローカルで実行すると、実際に再現可能な障害が確認されました: Error: Cannot find module ‘…/missing-server.js’.

壊れたバージョンを、意図的にデプロイしました。Hostinger が何を報告するかを見るためです。

Connector から取得できたビルドログには、依存関係のインストール成功しか表示されませんでした。欠けているモジュールによる実行時エラーは、そこには出てきませんでした。緑の “completed” バッジを見ただけの開発者なら、サイトが壊れていると疑う理由はありません。

復旧はスムーズでした。アシスタントは package.json をバックアップから復元し、ローカルでアプリを確認し、再デプロイし、デプロイ状態だけを信じるのではなく、ライブの /api/health エンドポイントを直接呼び出して修正を確認しました。

そのエンドポイントは稼働中の応答を返し、このテスト全体でアプリケーションが動いていることを実際に証明した唯一の証拠でした。

これは 2 つ目の大きな発見です。completed 状態は動作中のアプリケーションの証明ではなく、Connector 自身のログでもそれは分かりません。復旧そのものは、問題があると分かってからはうまくいきました。

ステータスバッジでは見抜けない障害を踏まえ、Connector の自信がどこまで本来の能力を上回るのか、次に環境変数を試しました。

環境変数の設定を試す

私はアシスタントに、害のない環境変数を追加するよう頼み、その前に Node.js の環境変数を管理する専用の Connector 機能があるかを確認し、なければ何もしないよう求めました。

利用可能なツールを検索した結果、Node.js の環境変数を管理する専用アクションは見つからず、コードやデプロイの変更をする前に停止しました。

これが、このテストの他の場面でも見たかった動作です。実際の制約に直面したとき、推測せずに止まりました。Hostinger Connector に環境変数のサポートがまったくないと結論づけるつもりはありません。ここでのテスト中には、そのようなアクションが公開されていなかった、というだけです。 

失敗と復旧のテストまとめ

このテストが信頼性について示すこと

Hostinger Connector は、日常的で決定論的な作業をうまくこなしました。

• 既知のデプロイ記録の読み取り
• 特定ファイルの編集
• ローカルコマンドの実行
• プロジェクトのパッケージ化
• 既知の Web サイトへのデプロイ
• ビルド状態の確認
• 利用可能なログの取得
• 既知の正常版の復元と再デプロイ

一方で、不完全なアカウントデータをまたいだ解釈が必要なタスクでは弱さが見られました。

• 新しく作成された Web サイトの特定
• ドメインのアクセシビリティと Web サイトの存在の区別
• completed ビルドがアプリの健全性を意味するかどうかの判断

このパターンは、アシスタントにどの程度の自律性を与えるかを判断する際に役立ちます。

リスクの低い確認には広めのプロンプトを使い、ライブのインフラを変更する作業には、より正確なプロンプトと明示的な確認条件を使ってください。

たとえば、次のように言う代わりに:

次のようにしてください:

2 つ目のプロンプトは、アシスタントの推測余地を狭めます。

使いやすさに関する総合評価

Hostinger Connector の起動は簡単で、ありがちなセットアップの面倒はなく、細かなツールカテゴリ制御によって、AI が触れる範囲を実際に調整できました。

実際にサイトが存在し、ドメインが分かっていれば、その仕事はうまくこなしました。1 行のコピー変更は、編集から本番反映まで約 1 分で進み、役立つビルドログも付いてきました。

問題は、後半ではなく前半にありました。まだ見つかっていない新しいターゲットに対して、Connector はドメインを作り出し、確認前にそれに基づいて行動しました。また、壊れたデプロイを、アプリが実際には停止しているのに “completed” と表示し、自身のログには実行時エラーも出していませんでした。これらの問題があるからといって、既存サイト向けのツールとして不安定になるわけではありませんが、新規デプロイとデプロイ後の状態は、信じる前に二重確認する必要があります。

Hostinger Connector Plans with Hostinger

Integrate Hostinger with the apps and services you already use to automate tasks, improve workflows, and manage your website more efficiently.

Hostinger を訪問する

サポートのレベル

Hostinger のサポートは、電話ではなくライブチャットとセルフサービスを中心に構成されているため、私は実際のユーザーがたどるであろう経路、つまり hPanel に組み込まれた AI アシスタント、人間へのエスカレーション、その前に開発者が参照するであろうナレッジベースを重点的にテストしました。

サポートチャネル

ライブチャットが、Hostinger が緊急時に開発者へ案内するチャネルであり、デプロイのデバッグ中に実際に使う可能性が最も高いチャネルなので、私はメールチケットではなく、その経路を直接テストしました。

ライブチャット: Kodee と人間への引き継ぎ

hPanel の “Ask AI” からライブチャットを開き、答えを間違える可能性が十分にある質問を Kodee に投げました。それは、Node.js デプロイで completed となったビルド状態が、アプリが実際に動いていることを保証するのか、そしてそうでない証拠はどこで見つかるのか、という質問です。

Kodee の最初の回答は具体的で正確でした:

“Completed” は通常、ビルド工程が正常に完了したことを意味します。起動後のアプリが正常であることを保証するものではありません。起動コマンドの誤りやその他の実行時クラッシュを見つけるには、ランタイムログを確認してください。hPanel で Websites → Dashboard → Deployments に進んでビルドログを開き、その後 app の stderr.log を nodejs フォルダ内で開き、Port already in use や Module not found のような起動エラーを探します。

この 1 回の回答だけで、私がこのレビューの前半で直面したまさにその曖昧さは解消できたはずです。Kodee は実際のログファイル名、正しいフォルダ、そしてビルド成功とランタイムの健全性の違いを、正しく示していました。

ただし、実際の人間の担当者にも確認したかったので、サポートエンジニアに直接つないでほしいと伝えました。

しかし、人間を呼ぶのは予想以上に難しかったです。ライブ担当者を直接求めても、Kodee は 2 回とも自分自身に戻そうとし、待つより速いとして次のように案内しました。

I understand why you’d want that. I can help you verify the build, start command, and runtime logs right here, which is usually the fastest way to pinpoint the issue.

Before we queue a specialist. I can resolve the issue and save you the wait.

Kodee が自分自身に戻すのをやめるまで、2 回の直接かつ明示的な依頼が必要でした。自分で解決できる質問なら、この手間は小さいでしょう。しかし、障害対応中で人に話したい場合には、かなり苛立たしいです。

その後に起こったのは、通常「ライブ担当者につないでください」で想像するようなライブの引き継ぎではありませんでした。Kodee は実際の仕組みを率直に説明しました。

I have shared your request with a specialist from our team who will personally review our chat and send me their answer, which I will then relay back to you here.

これは非同期の確認であり、ライブの転送ではありません。Kodee がインターフェースのままで、担当者が裏で会話履歴を確認し、答えが届いたら Kodee がそれを中継します。この違いは、エスカレーションを判断する読者にとって重要です。「human agent」と言っても、ここでは一般的なライブチャットのように新しい人がチャットウィンドウに参加するわけではありません。

その間も同じ技術的な話題を押し進め、正確なログパスと stderr.log が常に埋まっているのかを Kodee に確認しました。Kedee は、アプリが完全に起動しなかった場合や、別の場所にエラーを出した場合はログが空のことがある、と正しく述べ、堅実な回答を返しました。

担当者による確認は約 3 分後に届き、チャット内で Mayas というチームメイトの名前で示され、Kodee の回答を繰り返すだけではなく、より的確でした。

domains/[your-domain]/nodejs/stderr.log は正しい場所です。ただし、常に生成されたり埋まったりするわけではありません。uncaught exceptions や unhandled rejections のように、アプリが stderr に書き込んだ場合にのみエントリが表示されます。start コマンドが間違っていてプロセスが静かに終了した場合、stderr.log は空のままか、存在しないことがあります。

Mayas はさらに、Kodee が触れなかった 2 つの代替確認方法も追加しました。クラッシュ直前の最後の出力を見るために stdout.log を確認すること、そしてアプリが一度も完全に起動しなかった兆候として、起動確認の行がないか探すことです。

Knowledge Base

Hostinger のナレッジベースは、Getting Started、hPanel、Website Builder、Hostinger Horizons、Domains、DNS、Files Management、Email、MySQL Databases、Website、VPS、Agency Hosting Plans、Hostinger Reach、SSL Certificates、PHP、Profile Management、Billing、Affiliates and Referrals、Features、cPanel、About Hostinger という大まかなカテゴリで構成されています。

そのどのカテゴリにも Hostinger Connector 専用のものはありませんでした。正しい記事を見つける唯一の方法は “Hostinger Connector” を直接検索することで、結果は 5 件返りましたが、その大半は関連性が薄く、アフィリエイトマーケティングプラグインのガイドや一般的な Node.js ホスティングの記事などでした。

実際に Connector のセットアップを説明している記事のタイトルは “How to Set Up Web Hosting MCP on Local IDEs” で、Features → General Information に分類されています。

製品の実際のマーケティング名で検索すれば見つかりましたが、カテゴリをたどっている読者や “MCP” で検索する読者は、Hostinger のブランド名を知らないと見逃すかもしれませんし、宣伝名とドキュメント上の名称が一致していない点は、探し始める前に知っておく価値があります。

記事自体は、見つけさえすればよくできています。テストの 6 日前に更新されており、以下を網羅しています。

• 拡張機能を使った推奨のワンクリック OAuth セットアップ
• 拡張機能が直接サポートしない IDE 向けの、API トークンを使う手動セットアップ
• Mac、Linux、Windows 向けの正確な設定ファイルパス
• 完全な JSON 設定例
• 接続が成功したことを確認するステップごとの検証プロンプト
• サポート対象クライアントのうち自動検出されるものと、手動で設定を入力する必要があるもの

最後の点は、テスト中に実際に遭遇したことと一致していました。Devin Desktop は自動検出されますが、OpenAI Codex には手動方法が必要です。記事はその違いを正しく説明しています。

サポートに関する総合評価

Kodee の難しい技術質問への最初の回答は正確かつ具体的で、AI サポートアシスタントの中では珍しくない結果ではありませんでした。裏付けとなるナレッジベース記事も、見つければ最新かつ詳細です。ただし、製品の宣伝名とドキュメントのタイトルが一致していないため、カテゴリをたどるより検索のほうが確実です。

弱い点は人間へのエスカレーション経路です。Kodee は人間を求める私の依頼を 2 回も自分自身に戻そうとし、そのうえ “human agent” はライブ転送ではなく、同じチャットを通した非同期レビューを意味していました。いったん人間が確認すると、回答は Kodee よりも良く、より正確で、Kodee が示さなかった追加の診断手順も 2 つ含まれていました。

多くの質問では、Kodee だけで十分に正確な回答を素早く得られるでしょう。実際に人間に確認してほしいなら、1 回では足りないと思ってください。そして、ライブ会話ではなく、短時間待って中継される回答になると考えてください。

Hostinger Connector Plans with Hostinger

Integrate Hostinger with the apps and services you already use to automate tasks, improve workflows, and manage your website more efficiently.

Hostinger を訪問する

最終評価: Hostinger Connector は使う価値があるか？

はい、すでに Hostinger でホスティングしていて、エディタ内で日常的なデプロイを進めたい開発者には向いています。セットアップは数分で終わり、OAuth により API キーは不要で、Web サイトが既に存在しドメインも分かっていれば、Connector は約 1 分で本番更新を送り出し、ログも付けてくれました。Kodee のサポート回答も、実際の技術問題を最初の一回で解決できるほど鋭かったです。

ただし、信頼に関する注意点があります。見つからない新しいターゲットが相手だと、Connector はドメインを作り出し、確認前にそれに基づいて行動しました。

また、壊れたデプロイを、アプリが実際には落ちているのに “completed” と表示し、自身のログには実行時エラーも出しませんでした。既に存在するサイトで作業を速める用途には使えますが、新しいターゲットで行うことはすべて検証し、重要なデプロイの後はライブサイトを自分で確認してください。

Hostinger

5.0

2,471 user reviews

￥250 /mo

最低価格

Hostinger を訪問する

Rating based on expert review

• 使いやすさ
  4.9
• サポート
  4.9
• 機能
  4.8
• 信頼性
  4.7
• 価格
  4.5