ブログ on jqknono Blogs

Project Translator VSCode 拡張機能によるプロジェクト多言語ローカライゼーションの実現

https://blog.jqknono.com (jqknono) — Thu, 26 Feb 2026 14:00:00 +0800

Project Translator は強力な VSCode 拡張機能で、AI を活用してプロジェクトレベルの多言語自動翻訳を実現し、コード構造の完全性を維持しながら効率的にドキュメントのローカライゼーションを完了できます。

GPT-5.3-Codex 初体験：驚きから理性的評価へ

https://blog.jqknono.com (jqknono) — Tue, 17 Feb 2026 10:30:00 +0800

OpenAI は GPT-5.3 の正式版がまだリリースされていない時点で、先行して GPT-5.3-Codex という特化モデルを提供しました。ビジネスロジックから見ると、この決定は理解しやすいです。GPT-5.3-Codex は標準版 GPT-5.3 と同じ価格ですが、出力がより積極的で、実行時間が短く、メモリ使用量も少なく、より高い利益余地をもたらします。OpenAI にとって、GPT-5.3-Codex は明らかにコスト効率の高い選択肢です。

GPT-5.3-Codex のリリース初週は、使用体験が実際に驚くべきものでした。モデルの応答速度は以前のバージョンより明らかに優れており、コード生成のフィードバックも非常に迅速です。迅速なイテレーションや頻繁なインタラクションが必要な開発シーンでは、この効率向上が直感的な生産性改善をもたらします。短時間で複数の実装案を得たり、アイデアを素早く検証したりする必要がある場合、Codex の積極的な出力特性は特に有用です。

しかし、2 週目に入ると状況は顕著に変化しました。モデルの応答速度が大幅に低下し、かつてスムーズだったインタラクションがカクつき始めました。このような性能の揺らぎは、クラウドサービスでよく見られるリソーススケジューリングの問題を連想させ、ユーザー数の増加に伴うサーバー負荷分配戦略が原因でサービスが低下した可能性があります。

性能の揺らぎに加えて、注目すべきは Codex の思考の緻密さの不足です。非 Codex 系列と比較すると、複雑なロジックやエッジケースの処理、コードの堅牢性において弱い傾向があります。深い推論や多段階の計画、抽象的な理解が求められるタスクに直面した際、Codex は表面的に実行可能な案を提示しがちで、潜在的な問題の予測が欠如しています。

この差異は、二つのモデルが設計目標で異なることを反映しています。Codex は生成速度と出力の活性度に重点を置き、迅速なプロトタイプ開発、コード補完、シンプルなタスクの自動化に適しています。一方、非 Codex 系列はより強い汎化能力を保持し、解答の正確性と信頼性を重視します。

flowchart LR
    subgraph A["GPT-5.3-Codex"]
        direction LR
        A1["生成速度: 速い"]
        A2["出力活性度: 高い"]
        A3["思考の緻密度: 中程度"]
        A4["適用シーン: 迅速なプロトタイプ、コード補完、探索段階"]
    end

    subgraph B["GPT-5.3 非Codex"]
        direction LR
        B1["生成速度: 中程度"]
        B2["出力活性度: 安定"]
        B3["思考の緻密度: 高い"]
        B4["適用シーン: 本番環境、重要プロジェクト、安定期"]
    end

    A <-->|選択のトレードオフ| B

    classDef codex fill:#E3F2FD,stroke:#1565C0,stroke-width:2px,color:#0D47A1;
    classDef standard fill:#E8F5E9,stroke:#2E7D32,stroke-width:2px,color:#1B5E20;

    class A,A1,A2,A3,A4 codex;
    class B,B1,B2,B3,B4 standard;

実際の開発シーンを見ると、もしあなたのニーズがコードスニペットを迅速に取得したり、既知で明確な機能を実装したり、短時間で複数の案を試すことにあるなら、Codex の積極的な出力と高速な応答は明らかな優位性をもたらします。しかし、プロジェクトが安定期に入り、コード品質、保守性、長期的な安定性に対する要求が高まる場合、非 Codex 系列は依然としてより信頼できる選択です。

DoHとDoTの技術比較分析

https://blog.jqknono.com (jqknono) — Wed, 11 Feb 2026 00:00:00 +0800

DNS over HTTPS (DoH) と DNS over TLS (DoT) は、一般的な2つの暗号化DNS伝送方式です。それらは異なるプロトコルスタックを通じてDNSクエリの安全な伝送を実現します。DoTの標準は RFC 7858 によって定義されており、DoHは DNS Queries over HTTPS (DoH) によって標準化されています。これら2つの技術の本質的な違いを理解するには、ネットワークプロトコルの階層構造から分析する必要があります。

ネットワークプロトコルの階層構造

最新のネットワークプロトコルスタックは階層化設計を採用しており、各層は異なる機能を提供します。DNSはアプリケーション層プロトコルとして、特定の伝送方式にバインドされるわけではなく、複数の搬送プロトコル上で動作可能です。

アプリケーション層 (L7) には、HTTP/1.1、HTTP/2、HTTP/3、FTP、DNSなどのプロトコルが含まれます。注目すべきは、HTTP/3のセマンティクスは依然としてアプリケーション層にありますが、QUICが伝送の担い手となる点です。セキュリティ層はアプリケーション層とトランスポート層の間に位置し、主にTLSとその変種を含みます。TLSは通常TCP上で動作します（例：HTTPSやDoT）。DTLSはTLSのデータグラム版で、UDP上で動作可能です。QUICプロトコルは特殊で、プロトコル内部にTLS 1.3のハンドシェイクと鍵派生を直接統合しています。

QUICはL4.5層プロトコルと見なすことができ、UDPをベースに拡張され、従来のトランスポート層の機能を提供します。トランスポート層 (L4) には、TCP、UDP、QUICが含まれます。エンジニアリングの実装観点からはQUICはUDPに基づいていますが、信頼性、輻輳制御、多重化、暗号化ハンドシェイクなどの機能を備えているため、エンジニアリング的には独立したトランスポート層プロトコルとして扱われます。ネットワーク層 (L3) はIPプロトコル (IPv4/IPv6) を使用してパケットのルーティングと転送を担当します。データリンク層 (L2) には、イーサネットやWi-Fi (802.11) などの技術が含まれます。

TLSは暗号化手段として、アプリケーション層とトランスポート層の間で機能します。DoTからTLS暗号化を取り除くと、DoTは本質的にDNS over TCPになります。この階層化設計により、暗号化はオプションとなり、プロトコル自体の強制的な制約ではなくなります。

Plain DNSの特徴

最も一般的なDNSはPlain DNSと呼ばれ、UDPまたはTCP上で動作します。UDPは接続確立が簡単で、初回クエリ速度が速いため、最も一般的な搬送方式です。しかし、UDPの弱点は信頼性が低く、パケットがネットワーク内で消失しやすいことです。TCPはハンドシェイク回数が多く、初回接続速度はUDPより約30%遅いですが、長時間接続を確立した後は、応答速度はUDPと同じになります。

通信キャリアはネットワークが混雑すると、機器の負荷を軽減するためにUDPパケットを破棄することを選択することがあります。UDPパケットロスが深刻な地域のキャリアの場合、DNSクエリにTCPを使用するよう指定する方が有利な場合があります。TCPには再送メカニズムがあり、パケットロスが発生してもデータの確実な到着を保証できます。一方、UDPパケットを破棄しても小規模なキャリア設備の負荷圧は軽減されず、再試行により不確実性が増すだけです。

アプリケーション層のネスト

DNSとHTTPはどちらもアプリケーション層プロトコルであり、DoHは本質的にあるアプリケーション層プロトコルが別のアプリケーション層プロトコルをネストしたものです。DoHが必ずしもDNS over HTTPSである必要はなく、通常のHTTPを使用することも可能ですが、暗号化されていないDoHは平文リクエストであり、Plain DNSよりも利点がないため、ごく限られた特殊なニーズがある場合にのみ使用されます。

理論上は、DNS over FTPなど、任意のアプリケーション層プロトコル上でDNSを伝送できます。これは、対応するサーバーとクライアントを開発するだけです。この柔軟性は、アプリケーション層プロトコルの組み合わせの可能性を示しています。

flowchart TD
    subgraph L7["アプリケーション層"]
        A[DNS]
        B[HTTP]
        C[FTP]
    end
    
    subgraph Security["セキュリティ層"]
        D[TLS]
        E[DTLS]
    end
    
    subgraph Transport["トランスポート層"]
        F[TCP]
        G[UDP]
        H[QUIC]
    end
    
    subgraph L3["ネットワーク層"]
        I[IP]
    end
    
    subgraph L2["データリンク層"]
        J[Ethernet]
        K[WiFi]
    end
    
    A --> D
    B --> D
    C --> D
    D --> F
    E --> G
    H --> G
    F --> I
    G --> I
    H --> I
    I --> J
    I --> K
    
    style A fill:#e1f5ff
    style B fill:#e1f5ff
    style C fill:#e1f5ff
    style D fill:#fff4e1
    style E fill:#fff4e1
    style F fill:#ffe1e1
    style G fill:#ffe1e1
    style H fill:#e1ffe1

トランスポート層のネスト

QUICプロトコルはUDPに基づき、同時にトランスポート層でコネクション型のサービスを提供します。QUICは、TCPが持つコネクション型、輻輳制御、再送、フロー制御、フラグメンテーションと再構成などのトランスポート層機能を実装しています。TCPに比べてQUICはレイテンシが低く、UDPに比べてQUICはより高度で信頼性があります。

OpenRouter gpt-oss-120b モデルが中国語リクエストをサポートしていないデバッグ記録

https://blog.jqknono.com (jqknono) — Mon, 09 Feb 2026 22:00:00 +0800

OpenRouter が提供する無料モデル API を使用している際、戸惑う問題に遭遇しました。全く同じリクエスト構造で、プロンプトの言語を変更しただけなのに、全く異なる結果が出力されたのです。

問題の再現

openai/gpt-oss-120b:free モデルを使用してテストを行いました。2つのリクエストの唯一の違いは、プロンプトの言語だけです。1つ目のリクエストでは中国語のプロンプトを使用しました：

curl https://openrouter.ai/api/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer sk-or-v1-xxxxxxxxxxxxxxxxxxxxxx" \
  -d '{
  "model": "openai/gpt-oss-120b:free",
  "messages": [
    {
      "role": "user",
      "content": "你是一个专业的本地化翻译专家"
    }
  ]
}'

このリクエストは常に 429 ステータスコードを返し、リクエストが頻繁すぎるか、クォータ制限を超えていることを示します。しかし、英語のプロンプトを使用した場合：

curl https://openrouter.ai/api/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer sk-or-v1-xxxxxxxxxxxxxxxxxxxxxx" \
  -d '{
  "model": "openai/gpt-oss-120b:free",
  "messages": [
    {
      "role": "user",
      "content": "You are a professional localization translation expert"
    }
  ]
}'

リクエストは正常に応答し、期待されるモデル出力が返されました。

無料AIアイコン生成ツールまとめ

https://blog.jqknono.com (jqknono) — Mon, 02 Feb 2026 10:00:00 +0800

AI技術の進歩に伴い、デザイナーや開発者は現在、シンプルなテキストプロンプトを通じて素早く様々な種類のアイコンを生成できるようになりました。これらの無料AIアイコン生成ツールはデザインのハードルを大幅に下げ、専門的なデザインスキルを持たないユーザーでも高品質な視覚要素を作成できるようにします。以下のツールはすべてテキストによる画像生成をサポートしており、出力形式は通常PNGまたはSVGで、一部のツールではスタイルや配色の調整機能も提供されています。

Freepik AI アイコンジェネレーターは、テキストの説明に基づいてSVGまたはPNG形式のアイコンを生成できるオンラインAIアイコン生成ツールです。このツールはWebデザインやUIデザインのシーンに非常に適しており、無料ユーザーも利用可能ですが、1日の生成数に制限があります。アイコン素材を迅速に入手する必要があるデザイン作業において、Freepikは便利なソリューションを提供します。

Pixelcut AI アイコンジェネレーターは、シンプルで直感的なアイコン生成体験の提供に特化しています。ユーザーはテキストプロンプトを入力するだけで、カスタムアイコンを生成できます。このツールの操作フローはシンプルで明確であり、複雑なデザインソフトに不慣れなユーザーでも素早く使いこなせます。生成されたアイコンはそのままダウンロードして使用でき、個人のプロジェクトや小規模なWebサイトにビジュアルサポートを提供します。

IconScout AI アイコンジェネレーターは、シンプルなテキストによるアイコン生成をサポートし、多彩なスタイル選択を提供します。このツールは特にデザインプロジェクト、ブログ記事、プレゼンテーション用途に適しています。多様なスタイルオプションにより、ユーザーはプロジェクトのニーズに応じて適切なビジュアルスタイルを選択でき、全体的なデザインの一貫性を保つことができます。

QuillBot AI アイコンジェネレーターは無料のオンラインツールとして、ユーザーがテキストの説明を通じて素早くアイコンを生成できるようにします。このツールの大きな利点は、生成後に追加の変換手順なしで直接ダウンロードできる点です。この即利用可能な特性により、アイコン素材を迅速に入手する必要があるユーザーにとって理想的な選択肢となっています。

Recraft AI アイコンジェネレーターは、より高度なカスタマイズオプションを提供します。ユーザーはプリセットのスタイルを選択したり、既存のブランドイメージから一貫性のあるスタイルのアイコンを生成したりできます。また、カラーパラメータのカスタマイズもサポートしており、ブランドの視覚的アイデンティティを維持する必要のある企業にとって特に重要です。Recraftで生成したアイコンは、既存のブランド要素と視覚的な一貫性を保つことができます。

MiriCanvas AI アイコンツールは、無料のAIアイコンおよびロゴ生成ツールです。スタイルの選択とテキスト入力をサポートしており、シンプルな操作フローでアイコンを生成できます。このツールはユーザーエクスペリエンスを重視して設計されており、デザイン背景がないユーザーでも満足のいくアイコンを簡単に作成できます。

Perchance AI Icon Generatorは、登録不要、透かし（ウォーターマーク）なしの無料AIアイコン生成実験ツールです。その開放性と利便性により、一時的なプロジェクトやテスト用途には良い選択肢となります。アカウント作成やログインの手順がないため、ユーザーはすぐに使い始めることができ、この簡略化された使用フローは効率性を重視するユーザーに適しています。

OpenArt AI アイコンジェネレーターは、無料のAIアイコン生成機能を提供し、アプリのアイコンやその他の視覚要素をカスタマイズするために使用できます。このツールの生成能力は比較的包括的であり、完全なアイコンセットを作成する必要があるユーザーに適しています。テキストプロンプトで生成結果を制御することで、ユーザーは具体的なニーズに合わせてアイコンの詳細を調整できます。

flowchart TD
    A[AI アイコンジェネレーターの選択] --> B{使用ニーズの種類}
    B -->|迅速かつシンプル| C[Pixelcut<br/>QuillBot]
    B -->|プロ仕様のデザイン| D[Freepik<br/>IconScout]
    B -->|ブランドの一貫性| E[Recraft]
    B -->|登録不要| F[Perchance]
    B -->|完全なアイコンセット| G[OpenArt]
    B -->|スタイルの選択| H[MiriCanvas]

    C --> I{出力形式}
    D --> I
    E --> I
    F --> I
    G --> I
    H --> I

    I -->|PNG/JPG| J[Web用途]
    I -->|SVG| K[ベクターデザイン]
    I -->|両方| L[マルチシーン対応]

    J --> M[著作権条項に注意]
    K --> M
    L --> M

    M --> N[商業利用ライセンスの確認]

これらのツールは無料利用オプションを提供していますが、ユーザーは無料の利用枠や生成回数の制限に注意する必要があります。使用前には各プラットフォームの利用規約を、特に出力画像の著作権に関する説明をよく読む必要があります。一部のツールの無料版では商用利用が禁止されていたり、使用時に出典の明記が求められたりすることがあります。これらの制限条件を明確にすることで、将来的な法的リスクを回避できます。

Vibe Coding のコスト削減公式と臨界点

https://blog.jqknono.com (jqknono) — Wed, 07 Jan 2026 10:00:00 +0800

AIコーディングツールの課金モデルは、主に以下の3種類に分類できます:

Token課金: 各種API、Claude Code (Claude Pro)、Codex Cli (ChatGPT Plus)、智譜 Lite/Pro、Cursor新版などが含まれます。本質的にはすべてToken課金であり、一部の製品はパッケージ割引を提供しています。
API呼び出し回数課金: OpenRouter (無料枠)、ModelScope、Gemini Code Assistant (毎日1000回無料)、Chutesなど。
プロンプト回数課金: Cursor旧版 (500回)、Github Copilot (300回) など。

これら3つのモデルは本質的にすべて、モデル推論とコンテキスト処理に対して支払うものであり、違いは課金の粒度と上限の形式に現れます。

本文では、統一されたコストモデルを構築し、実用的な変数定義と計算式を提供して、異なるワークロードや方法におけるツール選択の臨界点を特定します。コストの検討には、現金支出、時間の消費、やり直しのリスクが含まれます。

統一された総コスト関数

任意のツール $i$ について、1つの課金サイクル内の総コストは次のように記述できます:

$$ \begin{aligned} \mathrm{Total}_i &= \mathrm{Cash}_i + \mathrm{Time}_i + \mathrm{Risk}_i \ \mathrm{Time}_i &= R \cdot \mathrm{Hours}_i \ \mathrm{Risk}_i &= R \cdot \mathrm{ReworkHours}_i \end{aligned} $$

ここで $R$ はあなたの時間単価（元/時間）です。時間を考慮したくない場合は $R$ を 0 に設定すると、式は純粋な現金コストの比較に簡略化されます。

変数の定義

3種類の課金モデルを統一するため、ワークロードを「セッション（session）」と「イテレーション（iteration）」の2つの階層に分割します。新しいプロジェクトに入る際のスキャンとインデックス作成は1回限りの操作であり、同じコンテキスト内での継続的な対話とコード修正は反復可能な操作です。

変数を定義します:

$S_i$: ツール $i$ の固定費用（サブスクリプション料または月額最低利用料金）
$N_s$: 本サイクル内の新しいセッション数（プロジェクト切り替え、コンテキストクリア、新規セッション開始をすべて含む）
$N_{it}$: 本サイクル内の有効なイテレーション回数（要件明確化、コード修正、エラー修正など）
$R$: 時間単価（元/時間）
$h0_i$: 新しいセッションごとのコールドスタート所要時間（時間）
$h1_i$: イテレーションごとの平均所要時間（時間）
$p_{\mathrm{fail},i}$: イテレーションごとの失敗によりやり直しが必要となる確率（0 から 1）
$h_{\mathrm{re},i}$: やり直し1回あたりの平均所要時間（時間）

したがって、時間とリスクの項は次のように記述できます:

Windows 上でリモートブラウザデバッグエントリを構築する

https://blog.jqknono.com (jqknono) — Thu, 01 Jan 2026 10:30:00 +0800

本文は、Windows ホスト上で Chrome を実行し、CDP 経由でリモートデバッグエントリを提供して、ローカルネットワーク内の Linux クライアントや MCP からの接続を可能にする方法を説明します。この方法の核は、Chrome が 127.0.0.1 だけをリスンし、portproxy で LAN アドレスにマッピングし、ファイアウォールで遠隔側の発信元を制限することです。

トポロジとフロー

下図は、Windows ホスト内部でのポートのフローと、クライアントが LAN アドレスからアクセスする方法を示しています。

flowchart TB
    subgraph Windows
        A[Chrome DevTools 127.0.0.1:9222] --> B[portproxy 192.168.31.2:9222]
        B --> C[Windows Firewall]
    end
    D[Linux Client] -->|CDP| B

    classDef local fill:#2c3e50,stroke:#ecf0f1,stroke-width:2px,color:#ecf0f1
    classDef proxy fill:#3498db,stroke:#2980b9,stroke-width:2px,color:#fff
    classDef firewall fill:#f39c12,stroke:#d35400,stroke-width:2px,color:#fff
    classDef client fill:#27ae60,stroke:#229954,stroke-width:2px,color:#fff

    class A local
    class B proxy
    class C firewall
    class D client

Chrome の起動

独立したユーザーディレクトリを使用し、remote debugging アドレスを明示的に指定することを推奨します。これにより、Chrome はローカルホストにのみデバッグポートを公開します。以下は 9222 ポートを例にした起動例で、実際の環境に応じて調整してください。

技术ブログは死んだ

https://blog.jqknono.com (jqknono) — Tue, 23 Dec 2025 17:05:13 +0800

過去数年間で、ChatGPTやClaudeといった人工知能(AI)執筆ツールが急速に普及した。これらのツールは流暢な技術記事を生成でき、人間の文章スタイルを模倣することさえ可能だ。こうした変化は技術ブログ界隈で広く議論を呼び、「技術ブログは死んだ」と声高に叫ぶ人々も現れた。本稿ではAIツールが技術ブログに与える影響と、技術ブログの将来の行方を考察する。

AI執筆ツールの台頭

AI執筆ツールの核となる能力は自然言語を理解し、高品質な文章を生成することだ。技術ブログ執筆者にとって、これらのツールは草稿の迅速生成、インスピレーションの提供、あるいは完成した記事の直接作成に利用できる。例えば、執筆者が複雑な概念を説明する必要があるとき、AIは明瞭な説明段落を生成できる。執筆者が時間に追われるとき、AIはチュートリアルを素早くまとめることができる。

しかし、この便利さには副作用もある。大量の低品質なAI生成コンテンツがインターネットに溢れ始めている。こうしたコンテンツはしばしば深みに欠け、誤りを含むこともあるが、SEO最適化のおかげで高いランキングを得て、真に価値ある技術ブログの露出機会を奪っている。

技術ブログの本来の目的

技術ブログは当初、開発者が経験を共有し、問題を記録し、個人ブランドを構築する手段であった。その価値は本物らしさと独自性にある。執筆者は実際の実践、思考、失敗体験を記事に込め、読者に一手の洞察を提供するのである。

AI生成コンテンツは見かけ上は専門的でも、こうした本物の体験を欠いている。AIは実際のプロジェクトで遭遇した問題を共有できないし、独自の解決策を提供することもできない。そのため、純粋にAIによって生成された技術記事は、本物の経験から生まれた作品に取って代わるのは難しいだろう。

人とAIの協働の未来

AIを脅威と見るより、むしろ支援者として捉えるべきだ。賢い技術ブロガーはすでにAIを活用して効率を高めている。AIでブレインストーミングを行い、文法チェックや表現の最適化、コード例の生成を行う。しかし、記事の核心的な見解や独自の洞察は依然として執筆者本人から生まれる。

こうした協働モードにより、執筆者は反復作業をAIに任せ、創造的な作業により集中できるようになる。最終的に生まれる記事は執筆者の個性を残しつつ、読みやすさと正確性が向上するのである。

技術ブログの変容

AIの衝撃に直面して、技術ブログは変容を余儀なくされるだろう。将来的な技術ブログは、より深い分析や独自の見解、インタラクティブ性を重視するかもしれない。例えば：

深掘り長文: 特定の技術領域を深く掘り下げ、AIが真似できない専門的洞察を提供する。
プロジェクト日誌: 実際の開発プロセスを記録し、成功と失敗の経験を共有する。
動画/ポッドキャスト: マルチメディア形式は感情や細部をよりよく伝えることができる。
コミュニティインタラクション: コメント欄やフォーラムなどを通じて読者と直接交流し、知識共同体を構築する。

こうした形式はいずれも人間の創造力と経験に依存しており、AIが現在のところ完全に代替するのは難しい。

結論

「技術ブログは死んだ」は誇張かもしれない。AIは確かに技術執筆の様相を変えたが、同時に執筆者に新たなツールも提供している。変化に適応し、AIを代替ではなく支援として活用できるブロガーは、消えるどころかむしろより高品質なコンテンツを生み出すだろう。技術ブログは死なない。より豊かな形で存続し続けるのである。

抜くサーバーは大得

https://blog.jqknono.com (jqknono) — Fri, 05 Dec 2025 11:51:04 +0800

長らく大得があるが、私はこれまで公開コミュニティで宣伝したことがない、それはアリババクラウドの抜くサーバーが非常に得だということだ。

長期大幅割引

タイトルバーに書かれた最大90%節約という表示は誇張ではなく、人気構成のサーバーは通常20%の割引、つまり2割引で、やや需要の少ない構成は9%の割引まで可能で、1割以下になる。

人気サーバーの一種は小規模入門サーバーで、2c2g、2c4gなどがあり、もう一種はCPU/メモリバランス型サーバーで、1:2(4c8g)、1:4(4c16g、8c32g)などがある。この種のサーバーは割引がやや少ない。

需要の少ない構成は通常CPU/メモリアンバランス型サーバーで、1:8(8c64g)、1:1(8c8g)などがあり、この種のサーバーは最大の割引を受ける。

今日の抜くサーバーを調べると、2c16gの方が2c8gより安い。なぜなら前者は9%、後者は14%の割引率で、逆転現象が起きているからだ。

アリババクラウドの抜くサーバーの割引率は動的に更新され、そのアルゴリズムは不明だが、私の使用シナリオで85%のコスト削減は確実にある。

抜くサーバーの使用前提

抜くサーバーを使用する核心はCPU/メモリと長期ストレージを分離し、長期ストレージには分離可能なクラウドディスク、OSS、NAS、データベースを使用できる。

クラウドディスクは地域に依存し、抜くサーバーの利用可能リソースも地域と強く関連しているため、クラウドディスクが最もIO性能の高い安定ストレージであるにもかかわらず、すべての地域で抜くサーバーが利用可能であるとは限らない。個人的にはこれを次点の選択肢とすることを推奨する。

その他三つのストレージはネットワークに依存し、アリババクラウドのイントラネット通信は無料で、IOレイテンシは高い可能性があるが、IO速度は許容範囲で、主にランダム読み書きがクラウドディスクより遅い。

OSSはアリババクラウドのオブジェクトストレージで、読み取り中心のファイル保存に適し、ネットワーク共有に適する。

NASはアリババクラウドのネットワークストレージで、各種ファイルの保存に適し、読み書きバランスが取れ、公共共有にはあまり適さない。

データベースは構造化データの保存に適し、計算とメモリ使用量は前述三者より多く、コストも高くなる。データベース自体は長期ストレージであり、クラウドディスクのような形態の長期ストレージに依存し、etcd、redisなどメモリに依存するデータベースタイプもある。

重要問題

抜くサーバーは長期業務を担えるか？

答えは肯定的で、寧屏広告除去は抜くサーバーを使用して長期業務を担っている。

抜くサーバーはどのように回収されるか？

無保護期間または1時間保護期間の抜くインスタンスを作成可能で、保護期間を過ぎると市场价格が入札価格を上回るか資源の需給関係が変化した場合、抜くサーバーは自動的に解放され、データバックアップ作業を確実に行うこと。

抜くサーバーには二種類の入札方法がある：

一つは保護期間を購入し、X時間の使用を約束し、その後市場状況に応じて解放する方法。解放には二種類の形式があり、一つはすべてのリソースを解放し、もう一つは計算リソースのみを解放し、クラウドディスク、IP、スナップショットを残す方法で、残されたリソースは引き続き課金される。運用は約束時間前に業務を新しいECSマシンに移行できる。

二つ目は保護期間を使用せず、市場リアルタイム価格で入札する方法で、確保リソースが逼迫すると、市場価格で入札しても回収される。

寧屏広告除去はKubernetesクラスタに依拠し、二つ目の入札方法を使用している。二つ目の方法は一つ目と比べてさらに約15%のコストを節約できる。

抜くサーバーの業務移行方法は？

核心は、アリババクラウドが抜くサーバーを解放すると決めた場合、5分前に通知が行われる点にある。

この5分以内に行うべきことは：

システム通知を識別し、抜くサーバーが解放されようとしていることを認識する
抜くサーバーの在庫を照会する
新しい抜くサーバーを購入する
サーバーを初期化し、業務に必要なコンポーネントをインストールする
弾性パブリックIPを移行するか、DNS解決を移行する
新しいサーバーをクラスタに参加させる
業務を移行する
古いサーバーをクラスタから除去する
古いサーバーを解放する

有料コンサルティング

本文の分析が示すように、抜くサーバーを使用することでサーバーコストの80%以上を節約できるが、計算とストレージの結合を分離する必要があり、相当の技術力が要求される。私は週末または深夜に有料コンサルティングサービス(1000円/時間)を提供でき、企業がこの目標を達成するのを支援できる。リモートデスクトップ環境の用意、コードベースアクセス権限、VS Code開発環境 + Claude Code(CodexまたはCursor)が必要で、私は業務コードアーキテクチャを迅速に分析し、分離方案を提示する。

アリババクラウドのESA_page機能はまだ使用しないことを推奨

https://blog.jqknono.com (jqknono) — Wed, 03 Dec 2025 19:16:52 +0800

これは ESA Pages 機能の制限で、このリソース規模では小さなウェブサイトをホストするのに十分です。長期的に更新するウェブサイトをホストしたい場合、2000 個のファイルの制限は低すぎます。

機能	制限項目	制限	説明
関数	応答時間	120 秒	関数の単一実行の応答時間は 120 秒を超えてはなりません（I/O 待機も RT 時間に含まれます）。
	待機時間	10 秒	ゲートウェイが Functions を待機する時間で、Functions が 10 秒以内にデータを返さない場合、ゲートウェイは接続を積極的に切断し、クライアントに 504 ステータスコードを返します。
	コードパッケージサイズ	4 MB	各関数の JavaScript コードファイルの上限サイズ。
	サブリクエスト数	4 個	Functions の単一実行で許可される fetch リクエスト数。
	開発言語	JavaScript（ES6 構文）	現在 JS のみサポート。JavaScript プログラミングスキルが必要です。
Pages	ファイル数	2000 個	各 Pages プロジェクトで最大 2000 個の静的ファイル（HTML、CSS、JS、画像など）をアップロード可能。
	単一ファイルサイズ	25MB	単一ファイル（動画、PDF、JS パッケージなど）の最大サイズは 25MB。
	パッケージサイズ	1024MB	プロジェクト全体のソースコード圧縮パッケージ（deploy package）の最大サイズは 1024MB。

参考ドキュメント

アリババクラウドドキュメント: ESA_page 機能制限