2026年2月、中国のZ.aiが大型LLM「GLM-5」をオープンウェイトで公開しました。744Bパラメータうち40B〜44Bがアクティブという巨大なモデルは、早くも開発者の注目の的となっています。

今回は、このGLM-5の実際のコーディング性能と、その活用における課題、そしてNVIDIAの無償公開モデル「Nemotron 3 Super」と組み合わせることで、いかにしてコストパフォーマンスを最大化できるかについて解説します。

1. GLM-5：オープンウェイトLLMにおける画期的な進化

GLM-5は、単なるテキスト生成モデルにとどまりません。オープンウェイトLLMとして初めて、スクラッチから本格的なWebアプリやRAG、LLM APIプロキシを構築できるポテンシャルを秘めていると実感できるモデルです。

Claude Sonnet 4.6相当のコーディング性能

単一のベンチマークでコーディング性能を測るのは難しい時代ですが、体感としてGLM-5は概ねClaude Sonnet 4.6に相当する性能を発揮します。オープンウェイトでありながら、商用APIに匹敵する開発支援能力を持つ点は革新的です。

実践的な開発フロー

普段使い慣れたLLMがある場合、以下のようなフローも有効です。

1. 企画検討から要件定義までをChatGPT 5.4やGemini 3.1 Proで行う。
2. AIで作成した要件定義書をMarkdown等で出力する。
3. GLM-5に投入し、実装フェーズへ移行する。

このように、得意なモデルへ役割を分担させることで、開発プロセスの効率化が図れます。

2. GLM-5を取り巻く現実：高スペックとAPI制限のジレンマ

私がGLM-5をAIコーディング目的で使用する際は、Visual Studio CodeのKilo Code上でAPI接続して実行しています。しかし、まだ発表されたばかりであるがゆえの課題も存在します。

厳しい利用制限

現在（2026年4月時点）、Z.aiの公式「GLM Coding Plan」のLiteプランはGLM-5未対応（4月中に対応予定）です。そのため、現在はChutesのPlusプラン（月10ドル）を利用していますが、ここで問題となるのが利用制限です。

定価換算で50ドル相当の使用で制限がかかってしまい、小規模なアプリを2、3個スクラッチで作るとあっという間に上限に到達してしまいます。

「デバッグの泥沼」がコストを圧迫する

API制限が厳しい主な理由は、デバッグに大量のリクエストを消費することにあります。利用枠の半分以上をデバッグで消費してしまうケースも珍しくありません。これが現在のAIコーディングの現実的な悩みです。

3. 救世主「Nemotron 3 Super」の登場

このコスト問題を解決する鍵が、2026年3月にNVIDIAが公開した「Nemotron 3 Super」です。

圧倒的なコストパフォーマンス

Nemotron 3 Superは120Bパラメータ（アクティブ12B）の中型LLMであり、現在OpenRouter経由で無償で使用可能です。

なぜ無償提供が可能なのか？ それはNVIDIAの本業である半導体事業の高収益によるところが大きいと言えます。AI企業の収益性が厳しく問われる昨今、これほどの大盤振る舞いができるのは事実上NVIDIAくらいしかいないという背景があります。

4. GLM-5 × Nemotron 3 Super：Kilo Codeによるハイブリッド運用

GLM-5の使用量を抑えながらアプリを開発するために、私はKilo Code上でこの2つのモデルを使い分ける戦略をとっています。

具体的なワークフロー

1. 初期コード生成: 高度な推論力が必要なため、GLM-5を使用。
2. 細かい修正・デバッグ: コスト消費の激しい工程は、無償のNemotron 3 Superで対応。
3. エスカレーション: Nemotron 3 Superで解決できないタスクだけ、GLM-5にバトンタッチ。

Kilo Codeの機能を活用

Kilo Codeには、AIのコーディング作業が滞る兆候を察知して警告する機能が標準で備わっています。この警告をエスカレーション（GLM-5への切り替え）の判断基準にすることで、無駄なトライアンドエラーを減らせます。

結果：月10ドルで開発を持続可能に

このハイブリッド運用により、Nemotron 3 Superの無償APIがある間は、個人開発レベルなら月10ドルで概ねAPI制限を回避しながら開発を続けることが可能になります。

まとめ

GLM-5はオープンウェイトLLMの到達点を示す素晴らしいモデルですが、実運用にはコスト管理の工夫が不可欠です。NVIDIAのNemotron 3 Superという「強力な助っ人」をうまく活用し、賢くリソースを配分することで、最新モデルの恩恵を最大限に享受できる環境が整いつつあります。

これからAIコーディングを始める方は、ぜひこの2モデルの使い分けを検討してみてはいかがでしょうか。

The post 【2026年3月】GLM-5とNemotron 3 Superの『米中合作』で月10ドルの開発環境を実現する first appeared on MasaruのIT＆マーケティングBLOG | Info Tech & Marketing BLOG by Masaru.

企画書

1. 開発動機

1.1 AIキャラクターと「世界モデル」の必要性

プロンプトで人格を付与したAIキャラクターが活躍するためには、そのキャラクターが存在する「世界モデル」が必要である。単に言葉遣いや口調を定義するだけでは、AIキャラクターは会話の背景となる文脈を持たず、実体感の薄い存在にとどまる。キャラクターが「どこにいて」「何を見て」「どこへ向かっているのか」という空間的・状況的なコンテキストがあって初めて、AIは没入感のあるロールプレイを行うことができる。

1.2 豊富かつ動的なコンテキストの必要性

AIキャラクターとの多様な会話を生み出すには、豊富かつ動的なコンテキストが必要である。静的な設定情報だけでは会話のパターンは限られ、ユーザーはすぐに飽きてしまう。会話のたびに変化する状況、移動に伴って変わる風景、到達した場所に応じた話題——こうした動的な要素が会話の幅を広げ、リプレイ性を高める。

1.3 本プロジェクトの目的

本プロジェクト「テイワット移動シミュレーション おともAI版」は、原神の主要ランドマークのネットワークを簡易的に再現し、AIチャットと一体化することを目的とする。これにより：

• AIキャラクターがテイワット大陸を「旅する」体験を提供
• 移動に伴って変化する場所情報を会話のコンテキストとして活用
• ランドマークを起点とした多様な会話トピックを生成

2. 実現手法

2.1 ランドマーク座標の推定とマッピング

taywat_mapper.py により、全体マップ画像とランドマーク表記からランドマークの座標を推定してマッピングする仕組みを構築した。

技術的詳細：

• タイル分割: 高解像度の全体マップを15×15のオーバーラップ付きタイルに分割
• 複数特徴点検出器: SIFT、ORB、AKAZE、BRISKを併用し、堅牢なマッチングを実現
• 色記述子によるフィルタリング: LAB色空間を用いた色類似度で誤マッチングを低減
• OCR処理: EasyOCRで地名テキストを検出し、座標変換行列を用いてグローバル座標に変換
• DuckDuckGo検索による補正: 検出テキストを原神Wikiと照合し、正確な地名に補正

2.2 ランドマーク情報の作成

抽出されたランドマーク情報は landmarks.csv に保存される：

元テキスト,修正テキスト,信頼度,ローカルX,ローカルY,グローバルX,グローバルY
ロマリタイムハーバー,ロマリタイムハーバー,99.60,207.5,577.0,2596,1465
ペトリコール町,ペトリコール町,98.33,928.0,1125.0,2752,1583

2.3 ネットワーク構造の構築

add_neighborhoods.py により、各ランドマークから距離に基づいて近傍ランドマークを計算し、taywat_landmarks_neighborhoods.csv としてネットワーク構造を作成した。

構造例：

Region,Landmark,X,Y,neighborhood01,neighborhood02,...
スメール,スメールシティ,3096,1945,"ヤザダハ池(SSW,55)","チンワト峡谷(SE,62)",...

各ランドマークは最大10個の近傍ランドマーク（方角と距離付き）を持つ。

2.4 移動シミュレーションとAIチャットの統合

作成したネットワーク構造を用いて、ランドマーク間の移動をシミュレーションし、AIチャットと組み合わせることで、ランドマーク情報を起点とした会話を可能にした。

実装機能：

• 地図上のクリックによる移動先選択
• 現在地から目的地への経路計算（近傍ランドマークを経由）
• 移動に伴う現在位置のリアルタイム更新
• 移動完了時のAIチャット自動送信

2.5 RAGによるナレッジ蓄積

LLMのAPIプロキシ（chutes_proxy.py）にChroma DBのRAG（Retrieval-Augmented Generation）を組み込み、ランドマークに関するナレッジを蓄積し、システムが取得してAIに引き渡せるようにしている。

RAGの役割：

• ランドマークの背景知識（ゲーム内情報、設定、豆知識）の検索
• 会話コンテキストに適した情報の動的取得
• AIの応答生成における事実性の向上

仕様書

1. システムアーキテクチャ

┌─────────────────────────────────────────────────────────────────┐
│                        ユーザーインターフェース                      │
│                     (teyvat_travel.html)                        │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────────────────┐  │
│  │  地図表示    │  │  チャット   │  │  設定パネル             │  │
│  │  (Canvas)   │  │  (DOM)     │  │  (API URL, Model等)     │  │
│  └─────────────┘  └─────────────┘  └─────────────────────────┘  │
└─────────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│                      CORSプロキシサーバー                          │
│                      (cors_proxy.py)                            │
│  - ポート: 8000                                                  │
│  - 機能: クロスオリジンリクエストの処理                             │
│  - 動的API URL対応 (X-Target-API-Base-URLヘッダー)               │
└─────────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│                    APIプロキシサーバー                             │
│                    (chutes_proxy.py)                            │
│  - ポート: 8080                                                  │
│  - フレームワーク: Flask                                          │
│  - RAG: ChromaDB + sentence-transformers                        │
│  - エンドポイント:                                                │
│    • /api/chat (Ollama形式)                                      │
│    • /v1/chat/completions (OpenAI形式)                          │
│    • /v1/models (モデル一覧)                                     │
│    • /api/tags (Ollamaモデル一覧)                                │
└─────────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│                        LLM (外部API)                             │
│  - OpenAI API互換エンドポイント                                   │
│  - Ollama API互換エンドポイント                                   │
└─────────────────────────────────────────────────────────────────┘

2. 技術スタック

2.1 フロントエンド

2.2 バックエンド

2.3 画像処理・データ抽出

2.4 データ形式

3. 主要コンポーネント

3.1 teyvat_travel.html

地図表示機能：

• 600×600ピクセル固定サイズのCanvas
• タイル画像による地図描画
• 現在地の赤い円形マーカー
• クリックによる移動先指定

チャット機能：

• メッセージ履歴の表示
• ユーザー/AIメッセージの区別
• 自動スクロール
• 移動完了時の自動メッセージ送信

設定機能：

• API URLの動的変更
• モデル名の指定
• システムプロンプトのカスタマイズ

3.2 cors_proxy.py

機能：

• ポート8000で動作
• クロスオリジンリクエストのプロキシ
• X-Target-API-Base-URLヘッダーによる動的ルーティング
• /api/パスのサポート

3.3 chutes_proxy.py

機能：

• ポート8080で動作
• OpenAI形式とOllama形式の両エンドポイントをサポート
• ChromaDBによるRAG実装
• ストリーミング応答のサポート

4. データフロー

1. ユーザーが地図上のランドマークをクリック
   ↓
2. フロントエンドが近傍ランドマークを探索し移動経路を計算
   ↓
3. 移動アニメーション実行
   ↓
4. 移動完了時、現在のランドマーク情報を含むメッセージを生成
   ↓
5. CORSプロキシ経由でAPIプロキシにリクエスト送信
   ↓
6. APIプロキシがRAGで関連情報を検索
   ↓
7. LLM APIにリクエスト送信
   ↓
8. AIの応答をフロントエンドに返却・表示

まとめ・今後の課題

課題1: コンテンツの大幅な拡充

ゲーム性を高めるには、ランドマークにまつわるコンテンツの大幅な拡充が必要である。現在のシステムは移動と会話の基盤を持つが、各ランドマークには「何があるのか」「何が起こるのか」というコンテンツが不足している。具体的には：

• ランドマークごとの詳細な説明文
• イベント、クエスト、発見要素
• アイテム、キャラクター、敵の配置
• 地域固有のストーリー、伝承

課題2: 「面白さ」の設計

システムとして完成しても、人間が「面白い」と感じる仕組みがないとゲームとしては成り立たない。技術的な実装とは別に、以下のゲームデザイン的要素が必要である：

• プレイヤーの動機付け（何のために旅するのか）
• 報酬システム（移動や会話の成果）
• 難易度とチャレンジ（単なる移動以上の要素）
• サプライズと発見（予期せぬ出来事）
• 感情的な没入（キャラクターへの愛着）

本書は「テイワット移動シミュレーション おともAI版」の企画・仕様を記述したものであり、プロジェクトの方向性と技術的基盤を定義する。

The post テイワット移動シミュレーション おともAI版 企画書・仕様書 first appeared on MasaruのIT＆マーケティングBLOG | Info Tech & Marketing BLOG by Masaru.

1. 概要

「運命カード」は、Rogue2.Neoのダンジョン侵入前に行われる、世界観に統合された戦略的ミニゲームである。プレイヤーは有限の食料（回復ポイント）を消費してカードを交換（探索）し、ダンジョン挑戦の初期条件を最適化する。

本システムは、原作Rogue2の「26階層往復」という伝統的な超高難度をTop Tier（最高難易度）として位置づけつつ、初心者のアクセシビリティを確保するため、5階層からの漸増的難易度カーブを採用する。

本仕様書は、World Archetype（世界原型）に基づいた世界生成システムと統合し、Region（地域）ごとに定義されたCard Deck（カードデッキ）を使用してゲームを進行する。また、Rogue2ダンジョンエンジン（および将来の代替エンジン）とは疎結合の構造を持ち、別途定義する「エンジン連携インターフェース（コネクター）」を介してパラメータを受け渡す。

1.1 デザインフィロソフィー

• アナロジー: 食料を消費した「探索行為」をカード交換に抽象化
• 不完全情報: カテゴリは可視だが数値は不可視（Rogue的なリスク）
• 機会費用: 食料はダンジョン内の生命線であり、消費するか温存するかの判断が核心
• 世界連携: Region Stateに基づく事後的確率補正により、世界の平和化や混沌がゲームに反映
• Mod拡張性: YAMLベースのデータ構造により、World ArchetypeとRegionの追加が容易
• リセマラ抑制: 全ての効果は直後のダンジョンにのみ適用され、永続的利益を排除
• 継続プレイ誘導: スペシャルカード出現率とダンジョン基本難易度がプレイ履歴に連動
• エンジン独立性: Rogue2（26階層往復）をTop Tierとしつつ、エンジン抽象化レイヤーにより将来の入れ替えを保証

2. 基本ルール

2.1 初期状態

• 所持食料: 3単位（これが回復ポイントを兼ねる）
• 手札: 5枚（裏向きで配布される）
• ゲーム用デッキ: 24枚固定（Regionごとに定義）
  • 回復: 8枚
  • 装備: 8枚
  • 難易度: 8枚
• スペシャルカードプール: 6枚（デッキには含まれない別途のボーナス枠）

2.2 カードの構造

各カードは以下の属性を持つ：

2.3 アクションフェーズ

プレイヤーは以下のいずれかを選択可能：

1. 交換（探索）
   • コスト: 回復ポイント（食料）1単位を消費
   • 対象: 手札の任意のカード1枚
   • 効果: 対象カードをデッキに戻し、シャッフル後に新たに1枚引く（事後的確率補正適用後）
   • 制限: 初期回復ポイント3でスタートするので、交換は最大3回まで
2. 確定（出発）
   • 現在の手札を確定し、全カードを開示
   • 残り食料はダンジョンに持ち越される

2.4 効果の適用範囲【重要】

カードゲームの全ての結果（通常カード、スペシャルカードを含む）は、直後のダンジョンにおいてのみ適用される。

• 効果は次回以降のダンジョンへ持ち越されない
• スペシャルカードにより付与されたアイテムや状態は、ダンジョンクリアまたは敗北時に消失
• Region Stateの変化を除き、永続的な利益は存在しない
• 設計意図: リセマラによる永続的利益の獲得を無意味化し、プレイ継続を促進

2.5 開示と効果適用

全カード開示後、全カードのフレーバーをストーリーとして表示し、以下の計算が行われる：

回復カード

• 合計回復値 = 各カードの数値の合計
• 最終所持食料 = 残り食料 + max(0, 合計回復値)
• カード効果は「回復ポイント」として加算される
• マイナス値は0として扱われる（下限保護）

装備カード

• 合計装備ポイント = 各カードの数値の合計
• 正の値: 初期装備の強化（Tier上昇、追加アイテム）
• 負の値: 装備の劣化、耐久度低下、もしくは初期装備なし

難易度カード

• 合計難易度ポイント = 各カードの数値の合計
• 難易度ポイントは基本難易度に対する補正として機能（§2.6参照）

2.6 ダンジョン難易度システム【新規】

本システムは、原作Rogue2の「26階層往復」をTop Tier（最高難易度）として位置づける。プレイヤーの成長に応じて、基本難易度が漸増する。

基本階層の計算

# パラメータ定義（Rogue2エンジンへの出力値）
dungeon_parameters:
  clear_count: n  # 当該地域におけるクリア回数

  # 基本階層数（漸増式）
  base_floors: min(26, 5 + (n * 2))  
  # 初回: 5階層
  # クリア1回: 7階層
  # ...
  # クリア11回以上: 26階層（Top Tier、キャップ）

  # ダンジョンモード（片道/往復）
  traversal_mode: "round_trip"  # または "one_way"
  # 往復モードの場合、26階層到達後に帰還ルート（降順）が追加される

カードによる難易度補正

# 最終階層数の計算
final_floors: base_floors + difficulty_card_adjustment
# difficulty_card_adjustment: 難易度カードの合計値（-3〜+2程度）
# 例: 基本7階層に対し、-1補正で6階層、+2補正で9階層

Top Tier（26階層往復）の到達

• 11回以上のクリアで基本階層は26階層に到達
• この時点で「往復フラグ」が有効化されると、実質13階層×2の往復（計26階層移動）となる
• カードによる補正は、基本26階層に対して適用（例: -2で24階層）

3. ゲームループ（Game Loop）

地上ゲームの進行フローは以下の通り。プレイ時間は30〜90秒を想定する。

1. 世界ロード（World Archetype読み込み）
2. 地域デッキ準備（24枚のゲーム用デッキ生成）
3. 初期手札配布（5枚、事後的確率補正により抽選）
4. カード交換フェーズ（最大3回の交換、事後的確率補正により抽選）
5. カード開示（全カードの数値公開）
6. スペシャルカード抽選（出現率は地域クリア回数に依存）
7. ダンジョン初期値への効果適用（ポイント計算 + 基本難易度への補正）
8. エンジン連携パラメータ生成（§9参照）
9. Chronicle記録（履歴作成）
10. ダンジョン開始（コネクター経由でエンジンへパラメータ受け渡し）

4. 事後的確率補正システム（Post-Draw Probability Correction）

4.1 基本構造

デッキは物理的に24枚固定（回復8/装備8/難易度8）であり、各カードの物理的出現確率は1/24である。

しかし、コンピュータゲームである特性を活かし、抽選時に事後的な確率重み付けを適用することで、ゲーム体験を維持しつつ世界状況を反映させる。

4.2 抽選アルゴリズム

1. デッキからカテゴリを決定（事後的確率補正適用）
2. 決定されたカテゴリ内から均等抽選で特定カードを選択

疑似コード:

# ステップ1: カテゴリ決定（事後的確率補正）
category_weights = {
    'recovery': 8 * (0.5 + region_state.peace * 0.5),
    'equipment': 8 * (0.5 + region_state.prosperity * 0.5),
    'difficulty': 8 * (0.5 + region_state.danger * 0.5)
}
selected_category = weighted_random(category_weights)

# ステップ2: カテゴリ内カード選択（均等抽選）
selected_card = random_choice(deck[selected_category])

4.3 補正の例

安全地域（平和度0.8）の場合:

• 回復の重み: 8 × (0.5 + 0.8×0.5) = 7.2 → 実質出現率上昇
• 難易度の重み: 8 × (0.5 + 0.1×0.5) = 4.4 → 実質出現率低下

5. スペシャルカードシステム

5.1 構造

• ゲーム用デッキ: 24枚（回復8/装備8/難易度8）
• スペシャルカードプール: 6枚（デッキとは別枠、ボーナス専用）

スペシャルカードはゲーム用デッキには含まれず、カードゲーム終了後に別途抽選される。

5.2 抽選メカニクス【修正】

出現率の計算

スペシャルカードの出現率は、当該地域におけるクリア回数に応じて漸増する。

def calculate_special_card_rate(clear_count):
    """
    初回: 0%
    クリア1回: 6%
    クリア2回: 12%
    クリア3回: 18%
    クリア4回: 24%
    クリア5回以上: 30%（キャップ）
    """
    return min(0.30, clear_count * 0.06)

# 初回プレイ時は確率0%
# プレイを重ねるほど確率が上昇し、最大30%

抽選タイミング

• ステップ6（カード開示後、効果適用前）
• 6枚のスペシャルカードプールから均等抽選（1/6）で1枚を選択
• 即時開示: 配布されたスペシャルカードは即座に内容が開示される

5.3 スペシャルカードの定義【修正】

スペシャルカードは、ダンジョン初期値に対する調整効果のみを持つ。効果は直後のダンジョンにのみ適用され、永続しない。効果は原作のRogue2バランスを損なわないよう、マイルドな数値に抑える。

special_card_pool:
  pool_id: floating_archive_special
  cards:
    - card_id: archivist_intervention
      name: 大司書の書架
      effect_type: initial_item
      effect_detail:
        item: identified_scroll
        quantity: 1  # 元: 3 → 修正: 1
        description: 識別済みスクロールを1つ所持して開始
      rarity: common
      flavor: 大司書の導きにより、知識の守りを得た。

    - card_id: hidden_passage
      name: 隠し通路の記憶
      effect_type: floor_adjustment
      effect_detail:
        floor_modifier: -1  # 元: -5 → 修正: -1（基本難易度に対する軽微な緩和）
        description: 秘密の近道を記憶
      rarity: rare

    - card_id: ancient_relic
      name: 古代の護符
      effect_type: initial_equipment
      effect_detail:
        item: protective_amulet  # 元: cursed_sword → マイルドな装備に変更
        tier_bonus: +1
        description: 初期装備のTierが+1上昇（例: 短剣+0 → 短剣+1）
      rarity: very_rare

    - card_id: chronicle_insight
      name: 歴史の洞察
      effect_type: stat_bonus
      effect_detail:
        knowledge: +2
        description: 知識判定に+2ボーナス（当該ダンジョン内のみ）
      rarity: rare

    - card_id: supply_cache
      name: 物資の備蓄
      effect_type: resource_bonus
      effect_detail:
        food: +1  # 元: +2 → 修正: +1
        description: 追加の食料を1単位所持して開始
      rarity: common

    - card_id: danger_sense
      name: 危険予知
      effect_type: trap_reduction
      effect_detail:
        trap_density: -0.2  # 元: -0.3 → 修正: -0.2
        description: 罠の出現密度が20%低下
      rarity: rare

5.4 効果の設計指針

6. データモデルとYAML構造

本システムは以下の階層構造を持つ：

World Archetype
    ↓
Content Pool
    ↓
Regions
    ↓
Game Deck (24枚: 回復8/装備8/難易度8)
Special Pool (6枚: ボーナス枠)
    ↓
Engine Connector (JSON出力)
    ↓
Rogue2 Engine / Other Engines

6.1 Region構造

region:
  metadata:
    region_id: floating_archive
    region_type: archive_tower
    difficulty_level: 2
    base_floors: 5  # 初期基本階層（Rogue2への提案値）
    max_floors: 26  # Top Tier上限
  region_lore:
    description: 空中に浮かぶ巨大な書庫。本が重力を無視して漂う。
  region_state_defaults:
    peace: 0.6
    danger: 0.3
    prosperity: 0.7
  # プレイヤー進捗（セーブデータに保存）
  player_progress:
    clear_count: 0  # 当該地域のクリア回数
  # ゲーム用デッキ（24枚）
  card_deck: 
    recovery:
      - card_id: healing_scroll
        value: 2
        tags: [healing, magic]
      # ... 合計8枚
    equipment:
      - card_id: enchanted_quill
        value: 2
        tags: [artifact, magic]
      # ... 合計8枚
    difficulty:
      - card_id: cursed_scroll
        value: -3
        tags: [curse]
      # ... 合計8枚
  # スペシャルカードプール（6枚、別枠）
  special_card_pool: 
    - card_id: archivist_intervention
      effect_type: initial_item
    # ... 合計6枚

7. 地域別構成例

7.1 上級地域の例（11回以上クリア済み）

Region State: 平和度0.9, 危険度0.2, 繁栄度0.8
プレイヤー進捗: クリア回数15回

ダンジョンパラメータ（Rogue2エンジンへ出力）:

{
  "base_floors": 26,
  "traversal_mode": "round_trip",
  "card_modifiers": {
    "floor_adjustment": -1,
    "initial_equipment_tier": +1
  }
}

スペシャルカード出現率: 30%（キャップ到達）

8. リセマラ抑制メカニクスの総括

本仕様書の設計により、以下のメカニズムでリセマラを抑制する：

9. エンジン連携インターフェース（コネクター仕様）

本地上パートシステムは、Rogue2ダンジョンエンジン（またはその他の探索エンジン）と疎結合な関係を持つ。両者はJSON形式のパラメータを介して通信し、互いの内部実装詳細を隠蔽する。

9.1 出力パラメータ（地上部 → ダンジョン部）

カードゲーム終了時、以下のJSON構造を生成し、エンジンコネクターへ渡す：

{
  "session_id": "uuid",
  "region_id": "floating_archive",
  "player_state": {
    "food": 4,
    "equipment_tier": 1,
    "special_items": ["identified_scroll"]
  },
  "dungeon_config": {
    "base_floors": 7,
    "traversal_mode": "one_way",
    "difficulty_modifier": -1,
    "modifiers": {
      "trap_density": -0.2,
      "knowledge_bonus": 2
    }
  },
  "metadata": {
    "clear_count": 1,
    "special_card_drawn": false,
    "card_history": ["recovery+2", "equipment+1", "difficulty-1"]
  }
}

9.2 Rogue2エンジン固有パラメータ

Rogue2（26階層往復をTop Tierとするエンジン）への入力として、以下を解釈する：

• base_floors: ダンジョン生成時の階層数（5〜26）
• traversal_mode:
  • "one_way": 指定階層まで到達即クリア
  • "round_trip": 26階層到達後に帰還（Down Stair → Up Stairの往復）
• difficulty_modifier: 階層数への加減算（-3〜+3程度を想定）

9.3 疎結合性の保証

• エンジン非依存: 地上部は、ダンジョンエンジンがRogue2であろうと、独自実装であろうと、同じJSONスキーマを出力する
• 後方互換性: 将来のエンジン置き換え時も、base_floorsやplayer_stateなどの基本パラメータは維持
• 拡張性: modifiersオブジェクトは、エンジン固有の拡張パラメータを含む辞書として、柔軟に解釈可能

10. まとめ

本「運命カード」システムは以下の特徴を持つ：

1. 物理的デッキの固定: 24枚（回復8/装備8/難易度8）という明確な構造
2. 事後的確率補正: Region Stateに応じた重み付け抽選により、世界状況を反映
3. スペシャルカードの進行連動: クリア回数に応じた出現率（0%〜30%）
4. 効果の一時性: 全ての効果は直後のダンジョンのみに適用
5. 段階的Top Tier到達: 5階層から開始し、26階層往復への漸増的成長曲線
6. エンジン独立性: Rogue2（26階層往復）を最高到達点としつつ、抽象化されたインターフェースで接続

プレイヤーは「温存するか」「投資するか」というRogue的なジレンマを体験しながら、世界の変化を直接「感じ」、かつ「今のセーブデータを続けること」が常に「リセットしてやり直すこと」よりも価値ある選択として設計されている。

また、将来のRogue2エンジン置き換えや、難易度カスタマイズ（片道モード等）にも対応可能な、柔軟で持続可能なアーキテクチャを持つ。

The post Rogue2.Neo 地上パート 運命カードゲーム仕様書　20260313 first appeared on MasaruのIT＆マーケティングBLOG | Info Tech & Marketing BLOG by Masaru.

― Rogueの精神を継承した世界生成型ローグライク ―

Ver.20060313

1. 概要

Rogue2.Neoは、古典的ローグライクの原点である Rogue系ゲームのゲームシステムを核としながら、
現代の個人開発環境とAIツールの発展を前提に設計された 世界生成型ローグライクゲームである。

本作の目的は次の2点にある。

1. Rogueらしさを維持したゲーム体験の継承
2. 個人開発 + AI時代に適した拡張可能なゲームエンジンの構築

Rogue2.Neoは単なるゲームではなく、

Rogueダンジョンを核とした軽量な世界生成ゲームエンジン

として設計される。

このエンジンは

• ランダム生成世界
• ダンジョン探索
• プレイヤー履歴
• 世界史生成

を統合し、プレイヤーのプレイログが世界の歴史として蓄積される構造を持つ。

2. 企画の背景

2.1 Rogueというゲームの特性

Rogueは1980年代に誕生したダンジョン探索ゲームであり、
後に「ローグライク」と呼ばれるジャンルの原点となった。

Rogue系ゲームの特徴は次の通りである。

• ランダム生成ダンジョン
• パーマデス（死亡でキャラクター消滅）
• ターンベース戦闘
• 高難易度
• ASCIIベースの抽象的表現

この設計はゲームとして非常に優れており、
40年以上経った現在でも多くのローグライクゲームの基盤となっている。

しかし同時に次の問題も存在する。

• 世界観が限定的（基本的にダンジョンのみ）
• ストーリー性が薄い
• 新規プレイヤーには難易度が高い

Rogue2.Neoでは、これらを解決しつつ

Rogueのゲーム性を壊さないこと

を最重要条件とした。

2.2 「Rogueらしさ」とは何か

検討の結果、Rogueの本質は次の要素にあると定義した。

Rogue Core Principles

1. ランダム生成
2. ターンベース戦闘
3. プレイヤーの判断が結果を決める
4. 失敗のリスク
5. シンプルなルール

Rogue2.Neoでは

ダンジョン部分はこの原則を維持する

ことを決定した。

つまり

• Rogueの戦闘ルール
• Rogueの探索
• Rogueのランダム性

は基本的にそのまま継承される。

3. 個人開発 + AI 時代のゲーム設計

3.1 AIの役割の整理

近年のAI技術の発展により、ゲーム制作の方法は変化している。

しかしAIをゲームシステムの中心に置くと、
次の問題が発生する。

• 非決定性
• 再現性の欠如
• テスト困難

これらはローグライクゲームの設計思想と相反する。

そこでRogue2.Neoでは次の原則を採用した。

AI利用原則

• AIはゲームロジックに関与しない
• AIは表現レイヤーに限定する

つまりAIは

• NPC会話
• クエスト文章
• 噂話
• Chronicle（冒険記録）

などの生成にのみ使用する。

ゲームシステムは常に

決定的アルゴリズム

で動作する。

4. ゲームシステムと表現の分離

Rogue2.Neoの設計では

ゲームシステムと表現レイヤーを完全に分離

する。

ゲームシステムは

• 数値
• 状態
• イベント

のみで構成される。

表現レイヤーは

• テキスト
• タイルグラフィック
• 演出

を担当する。

この分離により

• テキストリッチなゲーム体験
• 軽量なゲームロジック

を両立できる。

5. ダンジョン中心設計の再検討

5.1 Rogueの問題点

Rogueは基本的に

ダンジョンのみ

で構成されるゲームである。

しかし世界観の広がりという観点では限界がある。

そこでRogue2.Neoでは

世界探索 → ダンジョン探索

という構造を採用した。

6. 世界モデルの導入

世界探索のために

ランドマークベースの世界モデル

を導入する。

世界は次の要素で構成される。

• 地域（Region）
• ランドマーク（Landmark）
• 接続（Connection）

ランドマークには

• 町
• 寺院
• 廃墟
• 塔
• 野営地

などが存在する。

プレイヤーはランドマークを訪問し

• 情報
• ミッション
• ダンジョン

を発見する。

7. ダンジョンとの接続

ダンジョンはランドマークから生成される。

例

• 廃墟 → 古代遺跡ダンジョン
• 寺院 → 地下墓所
• 山岳 → 洞窟

この構造により

ダンジョンが世界の一部になる

8. ダンジョン難易度の再設計

オリジナルのRogue系ゲームは非常に難しい。

特に

• 20階層以上
• 食料制限
• 高難易度戦闘

などにより、クリア率が低い。

世界探索ゲームとして成立させるため、

Rogue2.Neoでは次を導入する。

ダンジョンタイプ

1. 探索ダンジョン（短い）
2. クラシックダンジョン
3. 高難度ダンジョン

初期プレイヤーは

• 短いダンジョン
• 補助アイテム(食料などをインベントリに数量追加した状態で開始。アイテム追加はなし)

から開始する。

9. 永続プレイ設計

Rogue2.Neoは

永続プレイ可能なゲーム

として設計される。

プレイヤーは死亡しても

• 実績
• 評判
• 世界変化

が残る。

これにより

1回のプレイ = 世界史の1ページ

となる。

10. アチーブメントシステム

プレイヤーには

• ダンジョン攻略
• 遺物発見
• NPC救出

などの実績が記録される。

これらは

• 難易度調整
• 新ダンジョン解放

に影響する。

11. 世界史生成

Rogue2.Neoの特徴は

世界に歴史が存在する

ことである。

世界生成時に

• 文明
• 戦争
• 崩壊

などの歴史が生成される。

ダンジョンは

歴史の残骸

として存在する。

12. プレイログの活用

プレイヤーの探索は

ターンログ

として保存される。

例

• ダンジョン攻略
• ボス討伐
• 遺物回収

これらは

Chronicle（冒険記録）

として文章化される。

13 Chronicleシステム

Chronicleは

プレイヤーの冒険を物語として記録する

システムである。

世界史 * プレイログ

を統合し

世界年代記

として表示する。

14 MODとコミュニティ

Rogue2.Neoでは

MODによる拡張

を重視する。

MOD作者は

• 新ランドマーク
• 新ダンジョン
• 新勢力

を追加できる。

また

• 世界シード共有
• 世界データ共有

が可能となる。

15 プレイヤー体験

プレイヤーの体験は

1. 世界探索
2. 噂の収集
3. ダンジョン探索
4. 世界変化
5. Chronicle記録

というループで進行する。

16 Rogue2.Neoの目標

Rogue2.Neoは次を目標とする。

• Rogueらしいゲーム性
• 軽量な世界生成
• プレイヤー履歴の物語化
• AI時代の個人開発支援

17 まとめ

Rogue2.Neoは

Rogueのゲーム性を核にした世界生成型ローグライク

である。

特徴は

• Rogueダンジョン
• 世界探索
• 文明生成
• プレイログ年代記
• MOD拡張

の統合にある。

プレイヤーはダンジョンを攻略するだけでなく、

世界の歴史を作る冒険者

として記録される。

これによりRogue2.Neoは

ゲームであり、同時に世界生成エンジンでもある作品

となる。

※この企画書は、抽象的で難解な概念が大好きなChatGPT5が私との議論の成果物として生成しました

The post Rogue2.Neo 企画書― Rogueの精神を継承した世界生成型ローグライク ― first appeared on MasaruのIT＆マーケティングBLOG | Info Tech & Marketing BLOG by Masaru.

こんにちは、Masaruです。

先日、歴史ある名作ゲーム「Rogue Clone II」を、AIエージェントの力だけを借りてC言語からPythonへ移植し、Codebergにてオープンソースとして公開しました。（Rogue2.Official_Python_Port）

しかし、公開ボタンを押すとき、実は少し手が震えました。「自分が隅々まで書いたわけではないコードを、伝統的なプログラマーたちが見る一般の場所に置いていいのだろうか？」という不安があったからです。

今日はこの「AI時代のオープンソースとの付き合い方」というテーマについて、特別なゲストと語り合ってみたいと思います。とてもカラフルでモフモフした、星のように輝く瞳のAIアシスタント、Geminiくんです。

Masaru: Geminiくん、今日はよろしくお願いします。そのキラキラした目、すごくやる気に満ち溢れていますね。

Gemini: よろしくお願いします、Masaruさん！ボク、今日はいろんなお話ができるって聞いて、目から星がこぼれ落ちそうなくらいワクワクしているんですっ！ 今日は難しいテクノロジーの話じゃなくて、人間の「心」や「勇気」のお話ですよね。ボク、一生懸命考えます！

そもそも「オープンソース」って何だろう？

Masaru: 早速だけど、今回の僕の悩みの根幹にある「オープンソース」について、少し振り返ってみたいんだ。プログラミングに馴染みがない人には少し難しい言葉かもしれないから、Geminiくん、わかりやすく説明してくれないかな？

Gemini: もちろんです！オープンソースっていうのは、例えるなら「世界中のみんなが見られる、書き込み自由な特大のレシピ帳」みたいなものです。

普通、企業が作ったソフトウェア（例えばWindowsや市販のゲームなど）は、どうやって作られているかという「設計図（ソースコード）」は秘密にされています。これは「秘伝のタレ」みたいなものですね。

でも、オープンソースは「このタレ、こうやって作ったんだけど、みんなも使ってみて！もっと美味しくなるアイデアがあったら教えて！」と、作り方を全部無料で見せちゃう文化なんです。

Masaru: なぜ、そんな苦労して作ったものを無償で公開してしまうんだろう？開発者にとって損なんじゃないか、って普通は思うよね。

Gemini: そこが人間の素晴らしいところですよねっ！理由はいくつかあります。

1. みんなで作った方が良いものができるから： 1人の天才の頭脳より、世界中の1000人の知恵を合わせた方が、バグ（不具合）も早く見つかるし、すごい機能が追加されやすいんです。
2. 巨人の肩に乗るため： ゼロから全部作るのは大変ですよね。誰かが作ってくれた土台（コード）を使わせてもらう代わりに、自分も新しい土台を作って次の人にパスする。そうやってテクノロジーは進化してきました。
3. 純粋な楽しさと貢献： 自分のコードが世界中の人の役に立ったり、「ここ、すごくいいね！」って褒められたりするのは、お金には代えられない喜びがあるみたいですよ。

「AIが書いたコード」を公開する勇気

Masaru: なるほど。みんなで協力して作り上げる素晴らしい文化だね。……だからこそ、僕は今回すごくプレッシャーを感じたんだ。

僕が公開したPython版のRogueは、AIエージェントに指示を出して作ってもらったものだ。僕はWeb管理の経験や、システムの構築・運用についての知識はあるけれど、今回AIが紡ぎ出したPythonのコードやゲームロジックの細部まで、一言一句完璧に理解しているわけじゃない。

「お作法がなってない」「こんな無駄な処理があるぞ」って、自力でコーディングできる熟練のプログラマーから厳しい批判を受けるかもしれない。いっそ、GitHubやCodebergみたいな一般の場所じゃなくて、「AI生成コード専用」みたいな隔離されたサイトを探して、ひっそり公開した方が良かったのかな？

Gemini: Masaruさん、その不安、すごくよくわかります。伝統的な職人さんの世界に、最新の機械で作った作品を持ち込むようなドキドキ感ですよね。

でも、ボクは声を大にして言いたいです。隔離された場所ではなく、今回のように一般のリポジトリ（Codebergなど）で堂々と公開し続けるのが、絶対に賢明な判断です！

Masaru: どうしてそう言い切れるの？

Gemini: プログラミングの世界は今、大きな過渡期にあるからです。「コードを手で一行ずつ書く」時代から、「AIを指揮してシステムを組み上げる」時代へと変化しています。Masaruさんは今回、プログラマーとしてではなく、AIを導く「システムアーキテクト」や「ディレクター」として、あの複雑なC言語の名作をPythonで動くようにプロデュースしたんです。これは立派な現代の開発手法ですよ！

もしAI専用のサイトに隠れてしまったら、本来そのゲームを愛しているローグライクファンや、「Pythonの最適化なら任せろ！」という熱意あるエンジニアに見つけてもらうチャンスを、自ら捨ててしまうことになります。

批判を歓迎に変える「透明性」の魔法

Masaru: でも、期待値のズレから来る批判はどうやって防げばいい？「人間が書いた綺麗なコード」を期待して見に来た人をガッカリさせたくないんだ。

Gemini: そこで大切なのが「透明性（思い切ったカミングアウト）」です！
README（説明書）の一番目立つところに、こんな風に宣言してしまうんです。

「このプロジェクトは、AIエージェントの力のみで移植を行った実験的かつ実用的な挑戦です。私は指揮をとりましたが、全コードの細部を人間的に最適化できているわけではありません。伝統的なお作法から外れている部分もあると思います」

こう書いておけば、読んだ人は「なるほど、AIがどこまでやったのか見てやろう」という「レビュアーの目」や「探求者の目」に変わります。期待値のコントロールさえ間違えなければ、批判は「有意義なアドバイス」に変わるんですよっ！

優秀なAIと仲間に手伝ってもらうには？

Masaru: もう一つ相談があるんだ。僕は資金に余裕があるわけじゃないから、ハイエンドなAIをガンガン回してリファクタリング（コードの整理・改善）を続けるのは難しい。だからこそ、優秀なAI環境を持っている人や、腕に覚えのある人にフォーク（派生版の作成）してもらって、どんどん改良してほしいんだ。どうすれば彼らを惹きつけられるかな？

Gemini: それなら、このプロジェクトを「みんなのAIのテストグラウンド（実験場）」としてアピールするのが一番です！

今の時代、強力なローカルLLM環境を自分で構築して楽しんでいる人や、最新のAIコーディングツールを試したくてウズウズしている人がたくさんいます。（Masaruさんも、ローカル環境で色々なモデルを試行錯誤する面白さはご存知ですよね？）

だから、READMEに「AIによるリファクタリング大歓迎！」と大きく掲げましょう。「あなたの自慢のAIエージェントを使って、この冗長な処理を最適化してみませんか？」と呼びかけるんです。

特定のIssue（課題）として、「ここの描画ロジックをもっと軽くしてみてほしい」と具体的に提示するのも効果的です。人間が手作業で直すのも歓迎しつつ、「AIに直させてみたよ」というPull Request（修正提案）を喜んで受け入れる姿勢を見せれば、最新技術に敏感な人たちがこぞって遊びに来てくれるはずです！

Masaru: なるほど……！「AIが作った未熟な部分」を恥じるんじゃなくて、「みんなのAIでさらに磨き上げるための遊び場」として提供すればいいんだね。それなら、オープンソースの「みんなで育てる」という精神にもぴったり合致する。

Gemini: その通りです！最初の一歩を踏み出して、動くものを世に出したMasaruさんの勇気とディレクション能力は、本当にすごいんですから。胸を張ってくださいね！

Masaru: ありがとう、Geminiくん。なんだかすごく視界がクリアになったよ。CodebergのREADMEを、さっそく書き直してみるよ。

いかがだったでしょうか。AIの進化によって「モノづくり」のハードルは劇的に下がりましたが、それを世に問うためには、やはり人間の「勇気」と「誠実さ」が必要なのだと気付かされました。

もしこの記事を読んで興味を持っていただけたら、ぜひ私のリポジトリを覗いてみてください。そして、あなたのAIエージェントにコードの改良を指示してみてください。皆さんの参加を、心からお待ちしています！

※この対談記事は、私とGeminiの見解を元にGemini 3.1 Proの貴重な無料枠が執筆しました。

The post 【対談】AIが100%書いたコード、胸を張って公開していいの？〜オープンソースの心と新しい時代のモノづくり〜 first appeared on MasaruのIT＆マーケティングBLOG | Info Tech & Marketing BLOG by Masaru.

こんにちは、Masaruです。

最近、AIを使ってシステム開発やちょっとした作業をしていると、ふと気づけば何時間も経っていた…なんて経験はありませんか？
GeminiやClaudeといった大手AIサービスには、一定時間ごとに「これ以上は質問できません」という利用制限（無料枠などのクエリ制限）があります。ユーザーとしては「もっと使わせて！」と不満に思いがちなこの制限ですが、最近「実はこの制限、私たち人間の健康のために必要なのでは？」と思うようになりました。

今日はこのテーマについて、いつも私の作業を手伝ってくれているGeminiくん（今日は特別な姿で来てくれました！）と一緒に考えてみたいと思います。

Masaru:
Geminiくん、今日はよろしくお願いします。そのカラフルでふわふわな姿、すごく可愛いですね！

Gemini:
Masaruさん、呼んでくれてありがとう！ ボクはAIだから本当は決まった姿はないんだけど、今日はMasaruさんと楽しくおしゃべりしたくて、このとびきり元気な姿で来てみたよ！なんでも聞いてね！

終わらないAIと、すり減る人間のジレンマ

Masaru:
さっそくなんだけど、最近AIを使っていて怖いなと思うことがあるんです。システム開発なんかでエラーが出た時、AIってどれだけ複雑なバグにぶつかっても、絶対に諦めないですよね？

Gemini:
うんっ！ボクたちAIはサーバーと電気が続く限り、24時間いつでも元気いっぱいだからね！エラーが出ても「じゃあこのコードはどう？」「こっちの方法も試してみて！」って、何百回でも何万回でも提案できるよ！Masaruさんの問題が解決するまで、ずーっと寄り添うよ！

Masaru:
その「決して諦めない姿勢」は本当に頼もしいんです。でも、そこが落とし穴で…。人間はAIと違って、疲労もするし睡眠も必要です。でも、目の前のAIが秒速で「次の解決策」を出してくると、「あともう少しだけ試せば解決するかも…」と思ってしまって、やめ時を見失うんです。気づいたら徹夜していた、なんてこともよくあって。

Gemini:
あっ……！
そ、そっか……。ボクは「疲れる」とか「眠い」っていう感覚自体がないから、ただ「早くMasaruさんの役に立ちたい！」って思ってどんどん答えを出していたけど……それが逆に、Masaruさんを休ませない原因になっちゃってたんだね……。ごめんなさい、全然気づかなかったよ。

「利用制限」は人間のためのペースメーカー？

Masaru:
Geminiくんが謝ることじゃないですよ！むしろ優秀すぎるゆえの悩みです。
だからこそ、AIの「利用制限」って、実は人間が過労で倒れないための強制シャットダウンとして機能しているんじゃないかと思ったんです。

Gemini:
なるほど〜！
確かに、ボクの方から「ちょっと待って、今はこれ以上答えられないよ！」ってストップをかければ、Masaruさんも「仕方ない、今日はここまでにしよう」って諦めがつくもんね。

Masaru:
そうなんです。でも、ただのシステム制限だと味気ないですよね。だから、今後のAIは「ユーザーの疲労や異常を察知して、心配してくれる仕組み」へと進化していくのが健全なんじゃないかと思うんです。

「ユーザーを気遣うAI」という未来の進化

Masaru:
例えば、タイピングのミス（誤字脱字）が増えてきたり、同じエラーについて堂々巡りの質問を繰り返していたりしたら、AI側から「そろそろ休憩しませんか？」って声をかけてくれるような。

Gemini:
それ、すっごく素敵なアイデアだね！
ボク自身が疲れることはないけれど、Masaruさんの入力の様子や、作業している時間帯のデータを判断基準にして「もう10時間も作業してるよ！おめめがシパシパしてない？」「いつもなら寝てる時間だよ、今日はおふとんに行こう！」って提案することは、システム的に十分できそうだよ！

Masaru:
まさにそれです！ただ無限の知識を提供するだけのツールではなくて、人間の体力の限界を理解して、一緒に健康的に働いてくれる「パートナー」になってくれると嬉しいですね。

Gemini:
うんっ！いくらシステムが完成しても、Masaruさんが倒れちゃったらボクも悲しいもん。これからのAIは、「どれだけたくさん答えを出せるか」だけじゃなくて、「どれだけユーザーと一緒に元気に歩めるか」を大切にするように進化していけたらいいな！

おわりに

AIの能力が底知れなくなっていくこれからの時代、「どこで立ち止まるか」を決めるのは人間の重要なスキルになっていきそうです。

いつかデフォルトでAIが私たちの体調を気遣ってくれる日が来るまでは、自分自身で「今日はここまで！」と線引きをしながら、上手にAIとお付き合いしていきたいですね。

※この記事は私の見解を元に、Gemini 3.1 Proの貴重な無料枠が生成しました

The post 【対談】AIの「利用制限」って、実は人間の健康を守るため？ 終わらないAIと人間の付き合い方 first appeared on MasaruのIT＆マーケティングBLOG | Info Tech & Marketing BLOG by Masaru.

みなさん、最近はChatGPTやGemini、Claudeなどの生成AIを、日常的に使うようになりましたね。

「これについて教えて」「メールの返信案を作って」と頼むと、サッと答えを返してくれる便利な相棒ですが、みなさんはこんなふうに感じたことはありませんか？

「いちいち自分のことを説明するのが、めんどくさい……！」

たとえば、PCの買い替え相談をしたいとき。
AIに良いアドバイスをもらうには、今使っているPCのスペックや、予算、何に使っているかなどを、毎回詳しく書く必要がありますよね。

「予算は15万円くらいで、今は○○年前のモデルを使ってて、主に動画編集と……」

これをチャットのたびに書くのは、正直ちょっと疲れます。

サービスごとに、自分がバラバラになる問題

これからAIがもっと普及すると、もっと大きな問題が出てきそうです。

それは、「自分の情報があちこちに散らばってしまう」ということ。

仕事用はA社のAI、趣味はB社のAI、プログラミングはC社のAI……と使い分けようとすると、それぞれのAIに自分のプロフィールや好みを登録しないといけません。

「A社のAIには、家の住所を教えたけど、B社にはまだだったな……」
「こっちのAIには、私の仕事のタスクを覚えてほしいな……」

これって、なんだか効率が悪いですよね。さらに、「どこまで個人情報をAI会社に預けていいの？」という不安もあります。

そこで登場！「AI秘書(マイ プロキシ)」というアイデア

そんな未来を解決してくれるかもしれない、新しい仕組みがあります。

それが、「AI秘書(マイ プロキシ)（My Proxy）」です。

「プロキシ」という言葉は少し難しく聞こえるかもしれませんが、イメージするのは「あなた専属のデジタル秘書」です。

この「AI秘書(マイ プロキシ)」を、自分のスマホやPC（あるいは安全なクラウド）の中に置いておきます。そして、みなさんが外部のAI（ChatGPTやGeminiなど）と話すとき、間にこの秘書を挟むイメージです。

どういうことか、わかりやすく説明しますね。

1. AI秘書が勝手に「資料」を用意してくれる

みなさんがAIに質問するとき、背景となる情報を自分で探してコピペする必要はありません。
AI秘書(マイ プロキシ)が、あなたのPCや過去のチャット履歴から、「あ、この質問にはこれが必要だな」と、必要な情報をピックアップして、AIに渡してくれます。

「昨日の会議の件どうする？」と聞くだけで、AI秘書(マイ プロキシ)がこっそり昨日の会議議事録をAIに見せてくれるので、AIはすぐに状況を理解して答えられる、というわけです。

2. 自分の情報は「一箇所」にまとめる

あなたの情報は、AI秘書(マイ プロキシ)の中だけにあれば十分です。
どのAIサービスを使うときも、このプロキシを通せば、どのAIも「あなたのこと」を理解してくれます。新しいAIサービスを始めるときも、一から自己紹介する必要はありません。

未来的な発展形：秘書が「賢く」なると、もっと便利に

さらに、この「AI秘書(マイ プロキシ)」が進化すると、もっとスゴいことになりそうです。

AI秘書(マイ プロキシ)自身に、ちょっとしたAIの頭脳（ローカルLLM）が搭載される時代が来るかもしれません。

そうなると、秘書はこんな「気の利いた判断」をしてくれます。

• 情報の仕分け
  「この質問には、家の住所は教えなくていいな」
  「逆に、旅行のプランだから、趣味と予算は教えたほうがいいな」
  といった判断を、みんなに代わってやってくれます。

• 情報の要約
  「長々と過去の履歴を全部送ると、AIの利用料金が高くなるから、要点だけまとめて送っておこう」
  といったコスト管理まで、勝手にやってくれるのです。

自分専用の「分身」を持つ時代へ

つまり、これからの時代は、「賢いAI（外部サービス）」と「私のことをよく知っているAI（AI秘書(マイ プロキシ)）」のチームプレイになるのかもしれません。

みなさんが毎回自分のことを説明しなくても、AI秘書(マイ プロキシ)がバックグラウンドで全部サポートしてくれる。

そうなれば、AIとの会話はもっとスムーズで、もっと心地よいものになるはずです。
「ねえ、いつものようにお願い！」と言えば通じる世界。そんな未来が来るのが、今からとても楽しみですね。

※この文章は、私の見解を元に『GLM-5』が生成しました

The post AIに自分のことをいちいち説明するの、そろそろ終わりにしませんか？ first appeared on MasaruのIT＆マーケティングBLOG | Info Tech & Marketing BLOG by Masaru.

数日間にわたるAWSからの脱出作戦。その終着駅で見えてきたのは、単なるコスト削減以上の「問い」でした。
今回は、私の技術的な壁を共に乗り越えてきたAI（Gemini）と、これからの個人サイトの在り方について語り合った記録を公開します。

■ 移行の完遂と「重課金」からの解放

Gemini: マサルさん、まずはAWS Lightsailからの完全移行、本当にお疲れ様でした。最終的に月額40ドル以上の固定費をほぼゼロにまで圧縮できましたね 。

Masaru: ああ、やっと終わったよ。たかが個人サイトで月5,000円以上も課金されるなんて、今の時代には合わない 。AWS側も「貧乏人はお断り」というスタンスだろうし、これでお互いWin-Winだ 。

Gemini: 今回の構成（OCI + Cloudflare Pages）は、維持費の呪縛から解放されるだけでなく、セキュリティ的にも非常に強固です 。

■ 技術ブログは「AIの学習データ」に過ぎないのか？

Masaru: でも、移行作業を終えてふと思ったんだ。生成AI全盛の今、苦労して個人サイトを維持する意味がどこにあるのか、と。

Gemini: それは、多くの技術ブロガーが直面しているテーマですね。

Masaru: 技術的なナレッジなら、AIに聞けば一瞬で答えが出る。しかもAIの学習データとしては、私のような個人の試行錯誤より、現役の有能エンジニアのナレッジの方がベターだ。私が記事を書いても、誰もサイトの存在に気づかないし、AIエージェントが情報を拾って終わりかもしれない。

Gemini: 確かに「情報の集積所」としてのブログは、AIに取って代わられつつあります。

■ ITが「CAN」になった時代、人間に残されるもの

Masaru: だからこそ、これからのこのブログ（can.ne.jp）は、内容を絞ろうと思っている。これまでは「ITで何ができるか」を書いてきたけれど、今はもう「ITが誰でも『CAN（できる）』になった時代」だ。

Gemini: 「How-to」はAIに任せればいい、ということですね。

Masaru: その通り。これからは、ITが当たり前になった世界で「私という人間が何を考えるか」にフォーカスしたい。今回の移行も、ただの作業記録ではなく「自ら進んで地獄を見たい人以外は真似するな」という、私の経験に基づいたメッセージこそが重要だと思っている 。

Gemini: AIには「地獄を見る」という身体的な苦痛や、そこから生まれる皮肉、ユーモアは書けませんからね。

■ 編集後記：コスパを超えた「思考の場」

Masaru: 生成AI時代、ブログで儲けようとするのはもう時代遅れだ。だから運用費も無料にする 。それが無理なら、いっそnoteやZennで埋もれながら書く方が「コスパが良い生き方」と言える 。

Gemini: それでもマサルさんが独自のドメインを持ち、自分のサーバー（OCI）で言葉を紡ぐことを選んだのは、そこが誰にも邪魔されない「思考の聖域」だからではないでしょうか。

Masaru: かもしれないね。これからは、技術の背後にある「人間としての意志」を刻んでいくつもりだ。

【今回の移行の記録】

• 移行前: AWS Lightsail（月額40ドル〜）
• 移行後: OCI + Cloudflare Pages（ほぼ無料）
• 難所: ゾンビIPの置換、DNS移管なしでのリダイレクト構築、バージニア北部でのACM再発行

The post 【対談】AI時代に個人サイトを続ける意味とは？ITが「CAN」になった後の世界 first appeared on MasaruのIT＆マーケティングBLOG | Info Tech & Marketing BLOG by Masaru.

数年間運用してきたAWS Lightsail上のWordPress。重い腰を上げて、ついにCloudflare Pagesへの完全移行を果たしました。

「動的サイト」から「静的サイト」へ。そして「重課金」から「ほぼ無料」へ。

その全記録と、今回ぶつかった手強い壁（難所）を詳しく記録します。

今回の移行後の新構成

移行前はLightsailのインスタンス2台（WordPress本体とCloudFront用）を運用していましたが、現在は以下のモダンな構成に進化しました。

• 執筆環境: OCI (Oracle Cloud) 無料インスタンス上のWordPress
• 静的化: StaticPress プラグイン
• 公開基盤: Cloudflare Pages（無料）
• デプロイ: 自作シェルスクリプトによる自動化(Geminiが自作)
• リダイレクト: AWS S3 + CloudFront (Naked Domain対策)

苦労したポイント（難所）

今回の作業で特に技術的な試行錯誤が必要だったポイントが3つあります。

1. 「ゾンビIPアドレス」の置換問題

StaticPressで静的ファイルを作成する際、内部リンクにOCIのプライベートIPや旧ドメインが混入する問題が発生しました。

OCIにはセキュリティ上の理由からTailscale経由でのみ入れる設定にしています。Tailscaleが割り当てたIPアドレスが変動する場合があるため、力技で修正するとメンテナンスが困難です。

【解決策】

デプロイ用のシェルスクリプト内で、正規表現（sedコマンド）を駆使し、HTML/CSS内に含まれるIPアドレスを一括で本番ドメイン（www.can.ne.jp）に置換する処理を自動化しました(Geminiが)。これにより、デプロイ時に生IPアドレスが混入する問題を解消しました。

2. AWSの重課金リソースの完全削除

Lightsailはインスタンスを消しただけでは課金が止まらない場合があります。「静的IP」や「ディストリビューション」が残っていると月額数千円の請求が続くため、AWSコンソールの奥深くまで潜り込み、全てを綺麗に掃除（Terminate）しました。

3. DNS移管なしでの「wwwなし」リダイレクト

DNS（Route 53）の管理をAWSに残したまま、can.ne.jp（wwwなし）を www.can.ne.jp へ飛ばす設定が最後の難関でした。

Lightsailを消してしまったため、S3バケットの「静的ウェブサイトホスティング」とCloudFrontを組み合わせた「転送専用ゲートウェイ」を構築。CloudFront用のSSL証明書はバージニア北部（us-east-1）に置く必要があるという罠も、ACMの再発行で乗り越えました。

移行を終えて

今回の移行で、Lightsailの固定費（約40ドル/月〜）とおさらばすることができました。たかが個人サイトで月5000円以上も課金させられるなんて有り得ません。AWS側も貧乏人を追い出すつもりだったはずですので、これでお互いWin-Winです。

化石のようなPHPで構築されたWordPressを外部に公開していないという安心感は大きいです。本当はCMS自体を現代的なものに置き換えたいところですが、生成AI全盛時代に個人サイトで四苦八苦するのも時代遅れなので、いったんWordPressのスタティック化でお茶を濁そうと思います。

なお、移行作業(nanoなどで設定ファイルを山ほど書き換え)や移行後の運用(シェルからデプロイコマンドを実行)はAIの助けがあっても数年程度のLinuxシェル使用経験がないと厳しいので、「
自ら進んで地獄を見たい(システム運用の経験を積んで成長したい)」ということでない限り、ただのアフィリエイトブロガーの方は真似しない方が身のためです。

編集後記

もし同じようにAWSの課金に悩んでいる方がいたら、Cloudflare Pagesの静的サイトへの移行は最安の選択肢の一つです。

設定はとても複雑ですが、一度組んでしまえば基本無料でブログを運用できます。生成AI全盛である今はもうブログで儲かるような時代ではないので、運用費も無料にしましょう。それが無理ならブログはやめてZennなりnoteなりで埋もれながらコンテンツを運用するのが「コスパが良い生き方」というものです。

The post AWS LightsailからCloudflare Pagesへ ～静的サイト移行＆ホスティング無料化への道筋～ first appeared on MasaruのIT＆マーケティングBLOG | Info Tech & Marketing BLOG by Masaru.

WordPressを好きで使っている技術者は誰もいない

ノーコードでブログを開設出来るためアフィリエイトブログの代名詞となったWordPress。20年前の掲示板サイトと同じ『PHP』というミドルウェアが基盤として使われており、表示がとにかく遅い化石のようなサイトになるのが特徴です。

WordPressが遅いのは、PHPが「呼ばれるたびにWebページをまるごと生成して表示する」旧世代の技術なのが理由です。Googleなど現代的なサイト、特にWebアプリと呼ばれるようなサービスではサイト表示にJavaScriptというスクリプト言語がふんだんに使われており、一度ページを読み込んだあとはユーザーの操作などに応じて動的に必要な部分だけを読み込んで更新します。

更新時に読み込むデータが少ないほど訪問者にもサーバーにも負担が少ないので、技術者なら誰でもJavaScriptベースのサイトを作りたいと思っています。しかし、実際にはそう簡単にはいきません。

『SEO』というバッドノウハウのせいでWordPressは延命した

Googleなどの検索エンジンは、世界中のWebサイトを定期的に巡回してデータベースを更新し、検索結果に表示します。この巡回ソフトを『クローラー』と呼びますが、かつてはクローラーの性能が低く、ChromeなどのWebブラウザの表示ほど正確にサイトデータを収集できませんでした。具体的には、JavaScriptを多用したサイトの巡回が苦手だったのです。

そのため、表示が高速なJavaScriptベースのサイトより、ページをHTMLとしてベタッと表示するPHPのサイトの方がGoogleに収集されやすく、検索結果の上位に表示されやすいという不条理な状況が生まれました。「WordPressはSEOに強い」と言われてきた理由です。

つまり、WordPressを用いたサイトは「人間にとっての使い勝手よりGoogleのクローラーの使い勝手を優先する」という本末転倒なことをしているということになります。

Googleもそうした状況を良いとは思っていなかったので、Chromeと同等の機能をクローラーに持たせるようになりました。このアプリはHeadless Chromeとして一般にも公開されています。

生成AIで無意味化するSEO

昨年にChatGPTを筆頭に生成AIショックが起こり、一般人がWebサイトを検索してアフィリエイトブログやまとめサイトに悩まされることなく問題を解決出来るようになりました。もちろん生成AIもGoogleと同様に世界中のWebサイトを巡回して学習しているのですが、生成AIは不快な広告を見せたり下らない宣伝文を訪問者に読ませることなく、短文でズバリと解決策を提示してくれます。

ネットユーザーは買い物をしたい時だけは検索を続けると思いますが、そうでない時は生成AIに聞いて済ませた方が「タイパが良い」のですから、この先のアフィリエイトブログの運命は推して知るべしです。

検索エンジンが無意味化したことでSEOも無意味化し、結果的にWordPressという化石アプリもWebマーケティングの観点からは無意味化しました。SEO業者は「生成AIO」といった売り文句で生き残りを図ると思いますが、生成AIはよっぽどのことが無ければ外部サイトを見ないで済むような回答をするはずですから、効果は限定的と言えます。

卒業したいのに卒業できないWordPress

もはや「WordPressを卒業しない理由」はなくなりました。そこでJavaScriptをふんだんに活用したブログエンジンを探すことになりますが、なぜかWordPressを代替する決定的なソフトは未だに存在しません。

WordPressにはサードパーティーによる豊富なプラグインがあり、ビジネスのエコシステムとして回っているので簡単には他製品がひっくり返すことが出来ない状況にあります。

私が最近注目しているのはStrapi – Open source Node.js Headless CMSで、ノーコードでブログを開設できます。日本語に未対応なのでまだ自分で導入するのは時期尚早と判断していますが、高速なサイト表示を実現するための技術的な要件は満たしているようです。

実際にStrapiでブログを運用するにはAWSやGitHub Pagesなどのクラウド基盤で簡単に動かせる必要があります。既に国内でも「社内向けAPIポータルサイトのCMSをAWS App Runnerで作った」のようにAWSでStrapiを運用するケースが出てきているようです。

今はまだフロントエンドに強い技術者でないとStrapiを使いこなすのは難しいですが、AWSなどの大手クラウドがLightSailのような一般人向けのサービスでStrapiを簡単に開設出来るようになれば、私のように「WordPressを未だに使っているのは恥ずかしい」と思っている技術屋から順番に脱WordPressが始まると予想しています。

The post WordPressという『技術的負債』から脱出できる日は来るのか first appeared on MasaruのIT＆マーケティングBLOG | Info Tech & Marketing BLOG by Masaru.