外形監視をどこに任せるか迷った。ラズパイでやるか、Cloudflareに任せるか。 外から見えるサービスの監視なら せっかくなのでCloudflare Workersにする。 自宅NWそこそこ落ちたりするので・・・。 ラズパイと比較した Cloudflare Workers ラズパイ 向いてる監視 外形監視（外からの死活確認） 内部NW監視 コスト 無料 電気代のみ メンテ ほぼゼロ たまに落ちる ローカルNW確認 ❌ ✅ 最小間隔 1分 自由 今回は wasutech.dev と blog.wasutech.dev、techblog.wasutech.dev の3つを監視したい。 Cloudflare Workers 無料枠で十分な理由 公式ドキュメント - Limits によると、無料プランは以下のとおり。 Cron Triggers: 5個まで リクエスト: 1日10万回まで CPU時間: 10ms/invocation 今回のユースケースは「HTTPリクエスト投げてステータスコード確認して Discord Webhook 叩く」だけなので、CPU時間は 2〜3ms で収まる。5分間隔で3ドメイン監視しても 1日864リクエストなので余裕。 コード全文 // src/index.ts const TARGETS = [ { name: "wasutech.dev", url: "https://wasutech.dev" }, { name: "blog.wasutech.dev", url: "https://blog.wasutech.dev" }, { name: "techblog.wasutech.dev", url: "https://techblog.wasutech.dev" }, ]; export default { async scheduled(_event: ScheduledEvent, env: Env, _ctx: ExecutionContext) { const results = await Promise.allSettled( TARGETS.map((t) => check(t.name, t.url)) ); const failures = results .map((r, i) => ({ result: r, target: TARGETS[i] })) .filter(({ result }) => result.status === "rejected" || (result.status === "fulfilled" && !result.value.ok) ); if (failures.length > 0) { const lines = failures.map(({ result, target }) => { const detail = result.status === "rejected" ? (result.reason as Error).message : `HTTP ${(result.value as Response).status}`; return `🔴 ${target.name} | ${detail}`; }); await notify(env.DISCORD_WEBHOOK, lines.join("\n")); } }, }; async function check(name: string, url: string): Promise<Response> { const res = await fetch(url, { method: "HEAD", signal: AbortSignal.timeout(10000), }); if (!res.ok) throw new Error(`HTTP ${res.status}`); return res; } async function notify(webhookUrl: string, msg: string) { await fetch(webhookUrl, { method: "POST", headers: { "Content-Type": "application/json" }, body: JSON.stringify({ content: msg }), }); } interface Env { DISCORD_WEBHOOK: string; } # wrangler.toml name = "wasutech-monitor" main = "src/index.ts" compatibility_date = "2025-01-01" [triggers] crons = ["*/5 * * * *"] Promise.allSettled を使った理由 Promise.all だと1つが失敗した時点で残りを待たずに throw する。 Promise.allSettled なら3つ並列でチェックして、全部の結果を集めてからまとめて通知できる。 1メッセージにまとめることでDiscordがスパムにならない。 ...

Cloudflareの通知をDiscord Webhookに流していたら、通知が大量に届くようになってしまった。重要なアラートが埋もれるので、Cloudflare Workers + Gemini APIで要約してから投稿するようにした。 方針 Cloudflareの通知設定で追加できるアラートはとりあえず全部有効にしている。各アラートが実際に役立つかは様子を見ながら判断する予定。 ただしセキュリティアラートはだいたい30分に数回届いたため、現時点では通知をスキップするようにした。それ以外のアラートは引き続き通知して様子見中。 構成 Cloudflare Alert → Worker受信 → フィルタリング（スキップ対象なら早期リターン） → Gemini API で日本語要約 → Discord Webhook に送信 前提 Cloudflare WorkersにDiscord Webhook通知のWorkerが既にある Google AI StudioのAPIキーを持っている モデル選定 Geminiのモデルは料金帯がいくつかある。 gemini-2.5-pro > gemini-2.5-flash > gemini-2.5-flash-lite Cloudflareアラートの要約程度であれば gemini-2.5-flash-lite で十分。一番安い。 最新のモデル名は公式ドキュメントで確認すること。 https://ai.google.dev/gemini-api/docs/models 実装 フィルタリングの考え方 頻度の高いアラートはWorker側でスキップできるようにしている。SKIP_ALERT_TYPES に列挙したタイプが一致した場合、Gemini APIを呼ばずに早期リターンする。不要なAPI呼び出しも減るのでコスト面でも良い。 どのアラートがどの alert_type を持つかはCloudflareの公式ドキュメントで確認できる。 https://developers.cloudflare.com/notifications/notification-available/ Worker コード // スキップしたいアラートタイプ（頻度が高くて邪魔なものを列挙） const SKIP_ALERT_TYPES = [ "security_alerts", // セキュリティアラート：30分に数回来るので無効化中 ]; async function summarizeWithGemini(apiKey, input) { const prompt = `以下のCloudflareアラートを日本語で3行以内に要約してください。重要度（🔴高/🟡中/🟢低）も判定してください。\n\n${input}`; const res = await fetch( `https://generativelanguage.googleapis.com/v1beta/models/gemini-2.5-flash-lite-preview-06-17:generateContent?key=${apiKey}`, { method: "POST", headers: { "Content-Type": "application/json" }, body: JSON.stringify({ contents: [{ parts: [{ text: prompt }] }] }) } ); const data = await res.json(); console.log("Gemini response:", JSON.stringify(data)); return data.candidates?.[0]?.content?.parts?.[0]?.text || "要約失敗"; } export default { async fetch(request, env) { if (request.method !== "POST") { return new Response("ok"); } let body; try { body = await request.json(); } catch { return new Response("invalid json", { status: 400 }); } // アラートタイプによるフィルタリング const alertType = body.text?.alert_type || body.alert_type || ""; if (SKIP_ALERT_TYPES.some(t => alertType.includes(t))) { console.log(`Skipped alert type: ${alertType}`); return new Response("skipped"); } // Geminiには常にbody全体を渡す const input = JSON.stringify(body).slice(0, 500); const summary = await summarizeWithGemini(env.GEMINI_API_KEY, input); const message = { username: "Cloudflare", embeds: [{ title: body.text?.title || body.text?.description || "Cloudflare Notification", description: summary, color: 0xF6821F, timestamp: new Date().toISOString() }] }; await fetch(env.DISCORD_WEBHOOK, { method: "POST", headers: { "Content-Type": "application/json" }, body: JSON.stringify(message) }); return new Response("ok"); } } シークレット登録 wrangler secret put GEMINI_API_KEY wrangler secret put DISCORD_WEBHOOK 動作確認 curl -X POST https://<your-worker>.workers.dev \ -H "Content-Type: application/json" \ -d '{"text": {"title": "テスト通知", "description": "これはテストです"}}' スキップ確認： ...

CloudflareのNotificationsはUIから1個ずつ設定するのがとにかくだるい。 種別も多いし、手動でDiscord Webhookを登録していくのは非現実的。 Cloudflare APIとWorkersを組み合わせて全通知を一括登録する。 構成 Cloudflare Notifications ↓ Cloudflare Worker (受け口) ↓ Discord Webhook Cloudflare NotificationsはWebhook送信に対応しているので、Workerを受け口にしてDiscordに転送する。 1. Discord Webhookを作成 通知を飛ばしたいDiscordチャンネルの設定から作成する。 チャンネル設定 → Integrations → Webhooks → New Webhook → Copy Webhook URL 2. Cloudflare Workerを作成 Cloudflareダッシュボードから Workers & Pages → Create → Hello World で作成する。 名前は cf-notify-discord など適当につけてDeploy。 エディタ画面で以下のコードに置き換える。 export default { async fetch(request, env) { if (request.method !== "POST") { return new Response("ok"); } let body; try { body = await request.json(); } catch { return new Response("invalid json", { status: 400 }); } const message = { username: "Cloudflare", embeds: [{ title: body.text?.title || "Cloudflare Notification", description: body.text?.description || JSON.stringify(body, null, 2), color: 0xF6821F, timestamp: new Date().toISOString() }] }; await fetch(env.DISCORD_WEBHOOK, { method: "POST", headers: { "Content-Type": "application/json" }, body: JSON.stringify(message) }); return new Response("ok"); } } Discord WebhookのURLはWorkerのSettings → Variables and Secretsでシークレットとして登録する。 ...

問題 ふとDesktopの画面を見るとモニターがマイクとスピーカーとしてOSに認識されていた。 誤って爆音で音が再生されるリスクが気になったため無効化することにした。 ついでにマイクも有効にする意味がない環境だったので止めた。 純粋な開発PCで動画とかも見ないそこそこ特殊？な環境なので最悪読み込まないなら何でもいい状態。 環境 OS: ArchLinux サウンドサーバー: PipeWire + WirePlumber 0.5.14 GPU: AMD Ryzen（APU） 問題のデバイス: AMD/ATI Raven/Raven2/Fenghuang HDMI/DP Audio Controller 原因 HDMI/DisplayPortには映像だけでなく音声も伝送できる仕様（Audio over HDMI）がある。 LinuxはこれをALSAレベルで別サウンドカードとして認識するため、 PipeWireがそのまま拾ってオーディオデバイスとして公開してしまう。 調査 認識されているカードを確認 pactl list cards short 49 alsa_card.pci-0000_04_00.1 alsa 50 alsa_card.pci-0000_04_00.6 alsa 2枚のサウンドカードが認識されている。詳細を確認する。 pactl list cards | grep -A 30 "alsa_card.pci-0000_04_00" 結果を整理すると： PCI アドレス ベンダー 説明 用途 0000:04:00.1 AMD/ATI Raven HDMI/DP Audio Controller モニター側（不要） 0000:04:00.6 AMD + Realtek ALC269VB Ryzen HD Audio Controller 本物のオンボードサウンド 0000:04:00.1 の alsa_mixer_name が ATI R6xx HDMI であることからも、 これがHDMI経由のオーディオデバイスだと確定できる。 ...

概要 はてな匿名ダイアリーとウーバーイーツをインフラレベルで封鎖したかった。 AdGuard HomeをProxmox LXCに立てて、Tailscale経由でDNSブロックする構成を作った。 環境 Proxmox VE Tailscale導入済み AdGuard Home v0.108.0 手順 1. AdGuard Home LXCをスクリプト一発で作成 Proxmoxのノードシェルで以下を実行する。 bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/adguard.sh)" community-scripts/ProxmoxVEが提供するスクリプト。 LXCのコンテナ作成からAdGuard Homeのインストールまで全自動でやってくれる。 デフォルト構成はDebian 13、CPU 1コア、RAM 512MB、HDD 2GB。DNS用途なら十分。 2. LXCにTUNデバイスを追加する TailscaleはWireGuardベースのVPNで、動作に/dev/net/tunが必要。 /dev/net/tunはLinuxの仮想ネットワークデバイス（TUNデバイス）。通常のネットワークデバイス（eth0等）は物理NICに紐づいているが、TUNはソフトウェアで作った仮想NIC。 Tailscaleは以下の流れで通信を処理する。 通信をTailscaleプロセスが横取り WireGuardで暗号化 暗号化したパケットを相手に送る この「横取り」の実装に/dev/net/tunを使う。TUNデバイスを通してカーネルのネットワークスタックとTailscaleプロセスがやり取りする仕組みになっている。 unprivileged LXCはセキュリティ上の理由でホストのデバイスに触れないようになっているため、明示的に/dev/net/tunをコンテナに見せてあげる必要がある。 Proxmoxのノードシェルで以下を実行してTUNを有効化する。 pct stop 106 echo "lxc.cgroup2.devices.allow: c 10:200 rwm" >> /etc/pve/lxc/106.conf echo "lxc.mount.entry: /dev/net/tun dev/net/tun none bind,create=file" >> /etc/pve/lxc/106.conf pct start 106 106の部分は自分のLXCのIDに置き換える。IDはpct listで確認できる。 3. LXCにTailscaleを入れる LXCのシェルに入って以下を実行する。 curl -fsSL https://tailscale.com/install.sh | sh tailscale up 認証URLが表示されるのでブラウザで開いてログインする。 認証後、TailscaleのMachines画面からAdGuard HomeのTailscale IPを確認しておく。 ...

背景 手持ちのWalkmanをLinux（Arch Linux）環境で活用したいと考えた。 単に音楽を聴くだけでなく、PCのファイルを転送したり、時にはPCの音を高音質で鳴らすオーディオインターフェースとして使いこなすのが目的だ。 ドキュメントを読む限り、最近のデバイスはMTP（Media Transfer Protocol）に対応しており、Linuxでも標準的なツールで扱えるはずだ。 環境 OS: Arch Linux File Manager: Thunar Device: Walkman (MTP/USB DAC対応モデル) Tools: usbutils, gvfs-mtp, libmtp, jmtpfs ThunarでWalkmanのFSが見えない WalkmanをUSBケーブルでPCに接続し、Thunarを開いたがサイドバーには何も表示されない。 まず物理的な接続を確認しようと lsusb を叩いたところ、コマンド自体が入っていなかった。 sudo pacman -S usbutils 改めて確認する。 $ lsusb Bus 001 Device 008: ID 054c:0c2f Sony Corp. Walkman デバイス自体はUSBレベルでは認識されている。fdisk -l にブロックデバイスとして出てこないのはMTPなので当然だ。 原因：MTP用ライブラリが未インストール gvfs-mtp と libmtp が入っていないのが原因だった。 sudo pacman -S gvfs-mtp libmtp # Thunarを再起動して反映 thunar -q これでThunarのサイドバーにWalkmanが表示され、GUIでファイルをコピーできるようになった。 補足：USB DACモードとは 調査中に「DACモードでなければ動かないのか？」と気になって調べたのでここにまとめておく。 USB DACモードとは、デバイスを「ストレージ」としてではなく、**「USBオーディオデバイス」**としてPCに認識させるモードだ。ファイル転送には使えない。 モード PCからの見え方 用途 MTP / MSC ストレージ ファイル転送 USB DAC オーディオデバイス PC音声出力 Walkman側の設定でどちらのモードになっているかは確認しておく必要がある。 ...

AI コーディングエージェントを飼い慣らす：最強の「AGENTS.md」の書き方 近年、Gemini、Claude、Aider といった「自律型 AI コーディングエージェント」が開発現場に浸透しつつあります。彼らは指示一つでファイル構成を理解し、コードを書き、テストを実行して修正まで行います。 しかし、エージェントを使い始めた多くのエンジニアが直面するのが、**「AI エージェントの暴走」**です。 型定義を面倒くさがって any を連発する プロジェクト独自のディレクトリ構造を無視して勝手に utils/ を作る vitest --watch などの終了しないコマンドを叩いてフリーズする 指示していないリファクタリングを始めて関係ないファイルを壊す これらの問題を防ぎ、エージェントを「熟練のペアプロ相手」に変える魔法のファイル、それが AGENTS.md です。本記事では、AI エージェントに守らせるべきルールを定義する AGENTS.md の書き方と、その設計思想を徹底解説します。 なぜ AGENTS.md が必要なのか AI エージェントは、人間が数年かけて培った「プロジェクトの阿吽の呼吸」を知りません。 エージェントに与えられるコンテキスト（ファイル内容や履歴）は有限であり、その中で彼らは「最も確率的に正しそうな推論」を行います。その結果、彼らはしばしば**「最も楽な道（＝技術的負債を生む道）」**を選んでしまいます。 AGENTS.md をプロジェクトのルートに配置する理由は、**「エージェントの推論空間に強制的な制約（ガードレール）を設けるため」**です。 なぜその設計にしたか：外部メモリとしての役割 エージェントは毎回ゼロベースで思考するわけではありませんが、多くのファイルを見すぎることで逆に重要なルールを見失う（ロスト・イン・ザ・ミドル現象）ことがあります。AGENTS.md という明確なルールブックを定義し、エージェントの起動時やタスク開始時に必ず読み込ませることで、思考のブレを最小限に抑えることができます。 AGENTS.md に書くべき内容の 4 つの分類 効果的な AGENTS.md は、以下の 4 つのセクションで構成するのがベストプラティスです。 禁止事項 (Prohibitions): 致命的なエラーや環境のハングを防ぐ 命名規則・コーディング基準 (Standards): コードの品質を一定に保つ アーキテクチャ原則 (Architecture): システムの整合性を維持する テスト・検証方針 (Testing): 修正の正しさを担保する それぞれのセクションについて、具体的な記述例を見ていきましょう。 1. 禁止事項 (Prohibitions) エージェントが最もやりがちな「環境破壊」を防ぐための最重要セクションです。 ルール 理由（なぜその設計にするか） インタラクティブコマンドの禁止 npm init や git commit (メッセージ入力待ち) など、ユーザー入力を待つコマンドは CLI エージェントをフリーズさせます。 Watch Mode の禁止 vitest --watch 等はプロセスが終了しないため、エージェントが「完了」を検知できなくなります。 any 型の原則禁止 AI は型の整合性を取るのが面倒になると any で逃げようとします。これは長期的な保守性を著しく低下させます。 勝手な依存関係の追加禁止 package.json を書き換えて新しいライブラリを入れる行為は、セキュリティやビルドサイズに影響するため、人間の許可を必須にします。 実例コード ## 禁止事項 - **コマンド実行**: - `vi`, `nano`, `top` などのインタラクティブなコマンドは実行しない。 - `npm start`, `vitest --watch` などの終了しないプロセスは背景実行 (`&`) するか、単発実行モードを使用すること。 - **TypeScript**: - `any` 型の使用は厳禁。どうしても必要な場合はコメントで理由を明記すること。 - **Git**: - ユーザーの明示的な指示なしに `git commit` や `git push` を行わない。 2. 命名規則・コーディング基準 (Standards) プロジェクトの「見た目」と「一貫性」を守るためのルールです。ここを疎かにすると、エージェントは自分の得意なスタイル（多くの場合、学習データで最も多いスタイル）で書き始めてしまいます。 ...

Canvas 2D API でピクセルアートタイルを「手書き」する実装テクニック 1. 概要 Web ゲーム開発、特にローグライクやタクティカル RPG を開発する際、避けて通れないのが「マップの描画」だ。通常、これらは「タイルセット」と呼ばれる画像ファイルを読み込んで描画するが、開発の初期段階や、あえて外部アセットに頼りたくない場合、Canvas 2D API を使ってプログラムで直接タイルを描画する「手書き（プログラマティック描画）」の手法が非常に強力な武器になる。 本記事では、HTML5 Canvas の fillRect や beginPath などの基本命令のみを使い、擬似的なピクセルアート風のタイルを描画するテクニックを解説する。画像を用意する手間を省きつつ、動的に色や形状を変更できる柔軟な描画システムを構築しよう。 2. タイル描画の基本構造 まずは、どのようなタイルでも共通して利用できる描画の入り口を作る。ピクセル座標ではなく、タイル座標（x, y）とタイルサイズ（tileSize）を受け取る設計にすることで、グリッドベースのシステムと統合しやすくなる。 /** * タイルを描画するメイン関数 * @param {CanvasRenderingContext2D} ctx - Canvasコンテキスト * @param {string} tileType - タイルの種類 ('wall', 'floor', 'grass', etc.) * @param {number} x - タイルのX座標（グリッド単位） * @param {number} y - タイルのY座標（グリッド単位） * @param {number} tileSize - 1タイルのピクセルサイズ * @param {string} fieldType - フィールドの種類 ('meadow', 'forest', 'mountain') */ function drawTile(ctx, tileType, x, y, tileSize, fieldType = 'meadow') { const px = x * tileSize; const py = y * tileSize; ctx.save(); ctx.translate(px, py); switch (tileType) { case 'floor': drawFloor(ctx, tileSize, fieldType); break; case 'wall': drawWall(ctx, tileSize, fieldType); break; case 'object_grass': drawFloor(ctx, tileSize, fieldType); drawGrass(ctx, tileSize); break; case 'object_tree': drawFloor(ctx, tileSize, fieldType); drawTree(ctx, tileSize); break; case 'stairs_down': drawFloor(ctx, tileSize, fieldType); drawStairs(ctx, tileSize, false); break; default: ctx.fillStyle = '#333'; ctx.fillRect(0, 0, tileSize, tileSize); } ctx.restore(); } この設計のポイントは、ctx.translate を使ってタイルの左上を原点 (0, 0) に固定することだ。これにより、各タイルの描画ロジック内で座標計算を簡略化できる。 ...

React + Canvas 2D API で作るターン制ローグライク：論理と描画を切り離す設計 React でゲームを作る際、多くの開発者が最初に直面するのが「DOM で描画するか、Canvas で描画するか」という選択です。特に数千枚のタイルや多数のユニットが登場するローグライクゲームでは、DOM 要素の管理はすぐにパフォーマンスの限界に達します。 本稿では、React の強力な状態管理（useReducer）と、Canvas 2D API の命令的な描画を組み合わせ、滑らかなアニメーションを実現しつつ堅牢なゲームロジックを維持する設計手法について解説します。 1. 概要：なぜ React と Canvas を組み合わせるのか React は「宣言的」な UI 構築に長けていますが、毎秒 60 回の頻度で数千の DOM 要素を更新するような動的な描画には向いていません。一方で、Canvas は「命令的」であり、ピクセル単位での高速な描画が可能ですが、状態と描画の同期を自分で行う必要があります。 この二つの「いいとこ取り」をするのが、「ロジックは React（useReducer）で、描画は Canvas で」 という役割分担です。 本記事で構築するアーキテクチャ Core Logic (useReducer): ゲームの「真実の状態（State of Truth）」を管理。ターン単位で離散的に変化する座標などを扱う。 Render Loop (requestAnimationFrame): Canvas 上で毎フレーム実行される描画処理。 Interpolation (補完): 離散的な論理座標を、滑らかな描画座標へと変換するローカル状態管理。 2. 設計判断：論理座標と描画座標の分離 ローグライクゲームは基本的に「ターン制」です。プレイヤーが右に移動したとき、内部データ（Core State）では x: 10 から x: 11 へと一瞬で書き換わります。しかし、これをそのまま描画すると、キャラクターがワープしたように見えてしまいます。 滑らかな移動（アニメーション）を実現するためには、以下の二種類の状態を明確に分ける必要があります。 なぜ分離が必要か 種類 管理場所 特徴 役割 論理座標 (Logical Position) useReducer (Global) 整数（タイル単位）。 当たり判定、AI、クエスト進行など。 描画座標 (Visual Position) Canvas 内の Actor クラス (Local) 小数点を含むピクセル単位。 滑らかな移動、揺れ、エフェクト。 判断理由： Core State にアニメーションの「途中経過（x: 10.2 など）」を持たせてしまうと、ゲームロジックが描画の都合に汚染されます。例えば、「まだ移動アニメーション中だから攻撃はできない」といった判定をロジック層で書く必要が出てき、コードが複雑化します。ロジック層は常に「今は（論理的に）どこにいるか」だけを知っていれば良いのです。 ...

React で作る堅牢なゲームセーブシステム：localStorage と Reducer を疎結合に保つ設計 ゲーム開発において、プレイヤーの進行状況を保存する「セーブ / ロード」は最も重要な機能の一つです。Web ブラウザで動作する React アプリケーションの場合、最も手軽な保存先は localStorage です。 しかし、単純に localStorage.setItem をコードのあちこちに散りばめてしまうと、テスタビリティが低下し、データ構造の変更（スキーマ変更）に弱いシステムになってしまいます。 本記事では、架空の RPG 『React Odyssey』を例に、SavePort インターフェースと Reducer の初期化関数を組み合わせた、クリーンで堅牢なセーブ / ロードの実装方法を解説します。 1. 概要：なぜ「直接 localStorage」を避けるのか React の useReducer を使ったゲーム開発では、ゲームの状態（State）は一つの大きなオブジェクトとして管理されます。これを JSON.stringify して localStorage に保存するのは簡単です。 しかし、以下の理由から、ロジックの中に直接 localStorage を書くべきではありません。 副作用の分離: Reducer は純粋関数であるべきです。セーブ処理（副作用）を Reducer の中に入れることはできません。 環境非依存: 将来的に保存先を IndexedDB やクラウド（Firebase 等）に変更したくなったとき、コードを大幅に書き換える必要が出てきます。 テストのしやすさ: localStorage が存在しない Node.js 環境（Vitest 等）でロジックのテストを行う際、モック化が容易である必要があります。 これらを解決するために、Dependency Inversion Principle（依存性逆転の原則） に基づいた設計を採用します。 2. SavePort 設計：抽象化の定義 まずは、ゲームエンジン側が必要とする「セーブ機能」のインターフェースを定義します。これを SavePort と呼びます。 // domain/save/save-port.ts /** * 保存されるデータの構造（スキーマ） * ゲームの現在の状態に加え、メタ情報を付与する */ export interface SaveData { version: number; // セーブデータのバージョン timestamp: string; // 保存日時 state: GameState; // 実際のゲーム状態 } /** * セーブ/ロードに関する抽象インターフェース */ export interface SavePort { /** データを保存する */ save(data: SaveData): Promise<void>; /** データを読み込む。存在しない場合は null を返す */ load(): Promise<SaveData | null>; /** セーブデータが存在するか確認する */ exists(): Promise<boolean>; /** セーブデータを削除する */ clear(): Promise<void>; } なぜインターフェースにするのか？ ゲームのメインロジック（UseCase）は、この SavePort を通じて読み書きを行います。この時点では「どうやって保存するか」は知らなくてよく、「保存できる」という事実だけに依存させます。 ...