滅するまでの記録

滅するまでの記録

滅するまでの記録です

プログラミング学習日記 2026/03/08 「戦国大名」をGo言語のBubbleTeaで勝手移植003 吉凶カードを作る

 というわけで家から吉凶カードを持ってきた。こんな感じでまだ切り離されてない新品である。でもゲームのコマは切り離されてるので新品として売ることも出来ないし、遠慮なくバラバラに・・

 

 複数枚あるものは1枚のみ選んである程度キレイに並べ・・

 

 スマホで撮影、GoogleDriveへアップロードしてPCへダウンロード、Antigravityの作業フォルダーに配置する。これを読み込んでOCRさせ、カードのインスタンス作成を自動化しようという狙いだが果たして・・?

 

 と、その前にCard構造体の設計を確定せねば。吉凶カードにはサイコロでの判定が指定されてるものがあるのでDiceフィールドを作って、出目によってのデータがString(国名)だったりInt(地域No)だったり不定なのでAny型って事で良いかな?

 

 そうそう、こう書けば・・むっ?

 

 おおぅ、そうだったスライスにしておけばIndexでそのまま選べるじゃないか。ちょっと昨夜は風邪引いて眠れなかったので思考力が落ちてる・・と、言うことにしておこう。

 

 と、ここまでやってようやく下ごしらえが終わったので新たにDescriptionフィールドも追加した上でインスタンスの作成を依頼

 

 完璧!!ゲーム制作で一番の面倒ポイントが解決された・・良い時代になったものですなぁ

 

 一部でエラー。カードをチェックすると8と9はIndex4でセットになってるのだった(なので要素数が合わない)。Anyなんだからスライスを混ぜても大丈夫だと思われる

 

 質問して正解を教えてもらう。OK

 

 さて、ではいよいよカードの効果を実装するわけだが・・Card.Nameをキーにして辞書内に格納したそれぞれのメソッドを呼びだして実行させるってアレがやりたい。Goでも出来るに決まってるけど、どう書けば?

 

 1、なるほど・・Type structじゃなくてType funcってのが書けるのか!

 2、ほうほう

 3、お〜なるほど!メソッドじゃなくて関数として実行するわけだな。まあ、一手間かかるが出来そうだ!作例としていくつか作って、あとはAntigravityにお願いできると効率が良いんだけど、さすがに難しいかなぁ?これが正確に実装されるようではもう人間の引退も近そうな気がするぜ・・

 

 えメソッド形式で呼び出すことも出来るのか!こりゃスゲェや!ようやくプログラミングやってるって感じになってきましたなぁ!

 ってところで続きは次回。ノドが痛いわ〜

 

プログラミング学習日記 2026/03/05 戦国大名をGo言語のBubbleTeaで勝手移植002

 確定申告も歯医者での定期清掃も終わったし続きをやるか!ちなみに確定申告はGPTにお世話になってスムーズに終わりました。今まで曖昧にやってたところもバッチリ解決して(?)、来年からは先送りしないでとっとと終わらせてしまおうと思いましたなぁ。

 

 まずはAntigravityで有効だったフォルダにマニュアルの画像を入れて、読み取って「いい感じ」でモックアップを作ってくれない?ってのがKiroでも出来るか?という実験。おおぅ・・今のところAntigravityにはトークンの制限も無いし、やっぱりGoogle、やってくれるぜ!最近全然検索してないけど(だからこそか)

 

 とりあえず明らかにおかしいところ(Mainが2つあるとか)を手動で訂正して実行したトコロ。BubbleTeaでの非同期実行のサンプルになっててちゃんと動きます。これをたたき台にして戦国大名の説明書片手にシステムの実装をしていきますか〜。全部Antigravityにやらせる実験もいずれしたいけど、まずはまあ人間様が学習をしないとね。

 

 ちなみに作ってもらった段階でのViewメソッドはこういう感じ。うーん、まあ良いんじゃない?お隣メソッドもちゃんと活用しててエラい

 

 Antigravityが作ってくれた構造体には結構抜けがある(プロンプトでそこまで指示してなかったのでしょうがないが)ので、マニュアルを読みながら必要フィールドを追加していく・・ってところでギョッ!GeneralsもProvincesも、これ入力補助でサジェストされたものです。やりおる!

 じゃあまずは最初の順番決定Phase(Antigravityが作ってくれた数字メソッドをIotaで生成ってのは性に合わないので慣れてる明示的指示方式に変えた。PhaseはStringの日本語(戦国だし!)で記述。戦国大名では毎ターン、ランダムでプレイヤーの行動順を決定するので、そのためのランダム化が必要なんだけど書き方忘れた!

 

 というわけで書いてもらいました。まあ、欲しいのはここで言うShuffleの部分だけだったんだけど・・あ、でもこの書き方だとPlayerに順番情報を持たせないといけないが?と思ったら

 

 そこんところもちゃんと自動でやってくれてました。やりおる!

 でもな〜・・構造的には、Playerに順番情報を持たせるのは面倒が過ぎるな。GameState.Playersの並びを変えるか、0〜Nのスライス(Index)をGameStateに持たせて、毎回シャッフルしてRangeでチンの方が楽だろう

 

 Shuffleの文法を聞いておく。なんだ、Lambdaの形は(i, j int)で固定なのか。つまり完全に固定されてるわけで、スライスを渡したらシャッフルするメソッドにしてしまおう

 

 固定なら中身を知る必要もないし最初からスライスを受け取る関数かメソッドにしてりゃいいのに・・ってのは見当違いか?

 

 というわけで、GameStateにOrderを持たせて、その内容だけ変更するとして、Shuffleは[]intの中身を混ぜるだけの関数にして

 

 こんな感じでEnter押したら終わりの処理にして

 

 続いては上では間違って内政フェイズになってるけど「吉凶札配布フェイズ」なんですよね。構造体はCardって事にして、種類を・・と考えてたけど

 

 種類はBoolで持たせたほうが良いか、と。本当は片方が決まればもう片方だから1つで良いんだけど、まあ、わかり易さ優先で・・

 

 当然GameStateにCardsフィールドを作って

 

 PhaseごとにViewで表示させる内容を変えないといけないので場合分けして・・。次は吉凶札のインスタンスを作らないといかんのだけど、これが説明書に内容が載って無くてカードを実際にチェックしないと駄目なんですよね。カードは家にあるので・・まあ、続きは次回ってことで良いか!

 なんかノッてきたぜ!

 

エレクトロカムイ2月第4週 大凶作

どうも!田和龍虎です。

今週の収穫は・・

 はい、またしても電源タップ多数。ほんで電池切れの落書きタブレット(ダイソーで500円で売ってるような奴)。いや今週も駄目だったわ〜・・しかし電源タップがもう在庫パンパンなので、バイト先で適当に配ろうかな。あると便利なんですよね!

 

 実はASUSのWindows8タブレットPCも拾いました。ちゃんと動くんですが・・Windows8じゃあねぇ・・というわけで、無理やりキーボードを接続してBiosからUSB起動にして軽量Linuxを入れてみるか!とトライ。が、なんかどれもこれもインストールが進まない。どういうこと?と思ったら、まさかの32BitCPUだった。ギブアップ!

 

 でもタブレットのケースについてたキーボードがBT接続だったので充電してチェック。OK、タッチパッドつきのBTキーボード、良いじゃない!もう3台くらい持ってるけど。

 

 更に外付けHDDをゲット。でも異様にガワがデカい・・これは・・分解してチェックすると容量なんと500GB、ダメだこりゃ

 

 あと、番外ですが以前ゲットしていたデジカメ。ソニーのおしゃれピンクとOlynpusの防水ブルー。知り合いの娘さんが修学旅行でオーストラリアに行くと言うので貸してあげました。海に入るって言うから防水もが良いだろうけど、画質はSonyのが圧倒的に良かったので。無事に帰ってこれるかなぁ・・そこだけが心配だ。今から考えたら、この写真を撮ってる例のクソスペトイカメラ、これだったら全く惜しくないのでこっちを貸し出せば良かった・・

 

 来週はお宝に出会えますように!

なんかClaude Codeを使えるようにならないとイカンのか?と思った、が

最近、よくClaude Codeって聞くんですよね(正確にはスマホのChromeトップページDiscoveryに記事が出る)。Claudeは使ってるけどClaude Codeとは?なんかCLIでコーディングのサポートをしてくれるというか丸々書いてくれるとか、Tmuxで並列で動かしてどーのこーとか。

一度試すか?と思ってClaudeに質問してみたら

「あ、課金必須です」

とのことだったので諦めたのが一昨日。そして今朝

 こんな動画がPivotで来てたので再生してビックリ。そういうものだったのか!

 でも・・別に仕事(宿直バイト)で役に立つわけでもないし〜・・プログラミングは相変わらずの盆栽気分だし〜・・それらに課金してまで何をするんだって話。

 そこで、Claudeに「Antigravityでこの動画で言ってるような機能を擬似的に実装出来るようなプロンプト書いてや」と人間だったらちょっと許されないような依頼をしてみた。

 

# Claude Code マルチエージェント体験を Antigravity で再現する

> **目的**: Claude Code の動画で見た「Skillsの自動更新」「複数エージェント並列稼働」を、  
> claude.ai (Antigravity) で疑似体験できる実践的なタスク集です。

---

## 🔑 コアコンセプトの対応表

|Claude Code の機能|Antigravity での再現方法|
|---|---|
|複数エージェント並列起動|「サブエージェントとして〜を実行してください」と指示で疑似並列|
|Skills 自動更新ループ|スキル改善ループをClaudeに明示的に実行させる|
|バックグラウンド実行|「先に〇〇を始めながら〇〇もやってください」という並行指示|
|エージェント間通信|「前のエージェントの出力を受け取ったものとして」という文脈引き渡し|

---

## 🧪 タスク1: Skills 自動改善ループの再現

**目的**: スキルのdraft → テスト → フィードバック → 改善 を1セッションで体験

### プロンプト(コピペして使う)

```
あなたは今から「マルチエージェント・スキル開発システム」として動作してください。
以下の3つの役割を順番に(必要なら並行して)こなしてください。

---

【Agent A: SkillWriter】
次のスキルのSKILL.mdドラフトを作成してください:
「ユーザーが日本語でビジネスメールの下書きを依頼したとき、件名・本文・結び文を
 適切な敬語レベルで自動生成するスキル」

SKILL.mdのフォーマット:
- YAMLフロントマター(name, description)
- 概要
- トリガー条件
- 出力フォーマット
- 具体的な手順

---

【Agent B: TestRunner】
Agent Aが作ったスキルに対して、以下の3つのテストケースを実行してください:
1. 「取引先への納期遅延のお詫びメール」
2. 「社内の上司への有給申請メール」
3. 「初対面の採用担当者への問い合わせメール」

各テストの出力を評価し、改善点を箇条書きで列挙してください。

---

【Agent C: SkillOptimizer】
Agent Bのフィードバックをもとに、SKILL.mdを改訂してください。
改訂前・改訂後の差分をわかりやすく示してください。

---

最後に:「このループをもう1回まわすべきか?」と判断して理由を述べてください。
```

---

## 🧪 タスク2: 並列コードレビューエージェントの再現

**目的**: 同じコードを複数の観点から「同時に」レビューする並列エージェント体験

### プロンプト

````
以下のPythonコードに対して、あなたは3人の専門家エージェントとして
【並行して】レビューを実施してください。
出力は3列(または3セクション)に分けて、それぞれ独立した視点で書いてください。

レビュー対象コード:
```python
def get_user_data(user_id):
    import sqlite3
    conn = sqlite3.connect("users.db")
    query = f"SELECT * FROM users WHERE id = {user_id}"
    result = conn.execute(query).fetchall()
    conn.close()
    return result
```

---

【Security Agent】セキュリティの専門家として:
- 脆弱性を発見し、CVSSスコアレベルで重大度を評価
- 修正コードを提示

【Performance Agent】パフォーマンスエンジニアとして:
- ボトルネックを特定
- 大規模データでの挙動を予測
- 最適化コードを提示

【Maintainability Agent】シニアエンジニアとして:
- コード品質、命名、エラーハンドリングを評価
- リファクタリング版を提示

---

最後に【Orchestrator】として3エージェントの知見を統合し、
優先順位付きの修正タスクリストを作成してください。
````

---

## 🧪 タスク3: 自律的プロジェクト分解エージェントの再現

**目的**: Claude Code の「タスクを自律分解して並列実行」を体験

### プロンプト

```
あなたはAIオーケストレーターです。
以下のプロジェクトを自律的に分解し、サブエージェントに割り当てて実行してください。

【プロジェクト】
「小規模飲食店向けの予約管理システムのMVP仕様書とプロトタイプコード」

---

Step 1 【Decomposer Agent】
このプロジェクトを並列実行可能な独立タスクに分解してください。
依存関係を明示したうえで、並列実行できるタスクグループを特定してください。

Step 2 【並列実行フェーズ】
以下のサブエージェントを"同時に"起動してください:

- [SubAgent-DB] データベーススキーマの設計(テーブル定義・ER図テキスト版)
- [SubAgent-API] REST APIエンドポイント一覧と仕様
- [SubAgent-UI] 予約フォームのHTMLプロトタイプ(シンプルで動作するもの)
- [SubAgent-UX] ユーザーストーリーと受け入れ条件

Step 3 【Integration Agent】
全サブエージェントの成果物を統合し、整合性をチェックして最終仕様書にまとめてください。
矛盾点があれば指摘し、解消案を提示してください。
```

---

## 🧪 タスク4: Skillsの自動トリガー最適化ループ(スキル記述改善体験)

**目的**: Skills descriptionの改善ループを体感する

### プロンプト

```
あなたはスキルトリガー最適化エージェントです。
以下のスキルdescriptionを、ユーザーが使いたいシーンで確実に発動するよう改善してください。

【現在のdescription】
「データの可視化を行うスキル。グラフや図表を作成したいときに使用する。」

---

【Iteration 1: Analyzer Agent】
現在のdescriptionの問題点を分析してください:
- どんなユーザー発言でトリガーされるか?
- どんな発言でトリガーされないか(見逃しパターン)?

【Iteration 1: Rewriter Agent】
分析をもとに改善版descriptionを3案作成してください。
各案に「想定トリガー発言の例5つ」を添えてください。

---

【Iteration 2: Evaluator Agent】
3案それぞれについて:
- トリガー精度(適切に発動しそうか): ★1〜5
- 過剰トリガーリスク(不要な場面で発動しないか): ★1〜5
- 説明の明確さ: ★1〜5
を採点し、ベスト案を選んでください。

---

【Final: Optimizer Agent】
ベスト案をさらに磨き、最終版descriptionを出力してください。
改善前→改善後の変化量を「Before/After」で見せてください。
```

---

## 🧪 タスク5: 「生きたドキュメント」自動更新エージェント

**目的**: Skills の継続的自動更新を擬似体験。ドキュメントが会話を通じて進化する。

### プロンプト(2ターン構成)

**ターン1:**

```
あなたは「プロジェクト知識ベース管理エージェント」です。
以下の初期ナレッジベースを作成してください。今後、私が新情報を伝えるたびに
あなたは自動的に更新・整合性チェック・バージョン管理を行います。

【プロジェクト名】AIチャットボット開発
【初期情報】
- 技術スタック: Python, FastAPI, Claude API
- チームメンバー: 田中(BE)、山田(FE)、鈴木(PM)
- リリース目標: 2025年Q2
- 現在のステータス: 設計フェーズ

ナレッジベースをMarkdown形式で構造化し、
バージョン v0.1 として出力してください。
```

**ターン2(フォローアップ):**

```
新情報です。以下をナレッジベースに統合してください:

1. 田中がフロントエンドも担当することになった(山田は退職)
2. 技術スタックにRedisを追加
3. リリースが1ヶ月延期されてQ3になった
4. バジェットが20%削減

【Agent Instructions】
- 変更箇所を差分ハイライト(変更前→変更後)で示す
- 影響を受ける他の記述も連鎖的に更新する
- リスクフラグ(⚠️)を新たに追加する
- バージョンを v0.2 に更新する
- 「このナレッジベースの健全性スコア」を100点満点で評価する
```

---

## 💡 使い方のコツ

### より「エージェントっぽく」感じるためのテクニック

1. **役割名を明示する** → `【Agent A】`, `【Orchestrator】` のように名前をつけると それぞれの視点が明確になり、並列感が増す
2. **中間出力を要求する** → 「Step 1が完了したら次に進む前に確認を求めてください」 と入れると処理の流れが見える化される
3. **フィードバックループを組み込む** → 「この結果に満足できなければ自律的に もう1ループ回してください」という指示で自律感が増す
4. **ツールの組み合わせを活用** → Web検索 + コード実行 + ファイル生成を 1タスクの中で組み合わせるとマルチモーダルエージェント感が出る

---

## 🎯 本物のClaude Codeとの違いと割り切り方

|項目|Claude Code|Antigravity|
|---|---|---|
|本当の並列性|✅ 真の並列実行|❌ 擬似並列(順次実行)|
|Skills永続化|✅ ファイルシステムに保存|⚠️ セッション内のみ(ストレージAPIで一部可能)|
|外部ツール連携|✅ Terminal, Git, ブラウザ|⚠️ Web検索・コード実行のみ|
|コスト|💰 API料金|✅ Proプラン内|

**割り切りポイント**: 「並列」は「複数の視点を同時に要求すること」と定義し直す。 実行順序より「マルチ視点の統合」という体験価値に集中すると満足度が高い。

---

## 🚀 次のステップ

これらのタスクを試したら、ぜひ「自分のユースケース版」にカスタマイズを:

- `【Agent A】` の役割をあなたの仕事の専門職に置き換える
- テストケースを実際の業務データに変える
- 出力フォーマットをあなたのワークフローに合わせる

**最終的なゴール**: このドキュメント自体をベースに、 あなた専用の「AIエージェントチーム」プロンプトを育てていくこと。

 

 という返答。うーん、なんかパッと見た感じ「なんか違うような・・」という気もした。もっと普遍的な仕組みみたいなのを期待してたんだけど・・

 

 ということで、今度はAntigravityに上の動画を読ませて「こういうの出来ませんか?」と質問

 

 うおお!心強い!懐にも優しいAntigravityはホンマ強い味方やでぇ・・ハッタリじゃなければね!

 基本的にAntigravityはフォルダを変えればプロジェクトが変わるので、プログラミングとは別で何かエージェント作業に特化した作業もやってみようかなぁ。まずは「なんかAIエージェントを使った作業に習熟できて、ついでにお金も稼げちゃうようなプロジェクト」を相談するトコロからかな・・

漫画「東島丹三郎は仮面ライダーになりたい」17巻までを読んだ

 

 アニメの2話までをそんなに期待せずに観て、ラストで受けた衝撃に

「とりあえずこの状態で原作を読んでみよう。普通は原作→アニメと進むんでアレが良くないコレがちょっと・・なんて思うけどアニメから入った場合の検証になるかもな」

と。

 そう考えてから随分時間が経ってしまった・・先週、ようやくマンガ喫茶に出かけたので報告というか感想と言うかメモ。

 まず1巻を読み始めて驚いたのが

・キャラクターの頭身が小さすぎる!これは酷い・・絵が下手くそになってないか?

 というものだったのだが・・ハッ!?と気づくと5巻くらいまで読み終わっていた。いつの間にかキャラクターのスタイルは良くなったな・・とか気づくことも出来なかった。

 その後、えっ?と気づくと1冊読み終わってる・・という体験が続いて、気づくと17巻読み終わっていた。こ、これは・・?

 一応言っておくと「バキ道」みたいにぺらぺらぺら〜っと中身がないのでひたすらページをめくるような体験とは全く違った。要するに意識を失うと言うか自我が喪失するというか、つまりとんでもなく久々な体験だと思うんだけど子供の頃に体験してたような気がするな〜というアレ!初期の「マイホームヒーロー」を読んでたときにタマに経験したあの「はっ?俺って誰だっけ?」という自我を失うレベルでの没入感が延々と続いてるという感じなのだった。

 つまり、何が言いたいかというと・・このマンガスゲーッ!と。話が面白いってのは当然として、、マンガのネームとかコマ運びとかストーリーテリングとか・・そういうテクニックの部分で何か秘密・秘訣みたいなのがあると感じた。

 

 そして思ったね。このマンガは「この後こうなるな」だとか「これってこういう事だろうな」なんて小賢しい読み解きや考察なんかは無用なんだと。ただただ流れに身を任せて楽しむ、そういう体験が、僕みたいな擦れっ枯らしのマンガ読みにも許される稀有な存在だ・・。

 ああ・・でも・・多分ラスト直前辺りに出るだろう「怪人飛蝗男」とのバトルはどうなってしまうんだろうか・・と期待が止まらんぜ!

 

 あ、それと肝心のアニメとの比較ですけど。結局マンガを最新コミックまで読んでしまったのでいつものように「原作ありき」の感想になってしまいそうだけど、それでも「アニメ版すごく良い!」と言わざるを得ないな。原作版の超没入ドライブ感と相克する表現手段だからしょうがないけど(それでも相当テンポが良いと感じた)、効果音、特撮部分のアニメでの再現は原作では不可能(特撮ファンは脳内で補完可能)、それをマスに伝えようと思った場合の最適解となってるんじゃないだろうか!

 というわけで今からアニメ版の3話からを、姿勢を正して、観るぜ!

プログラミング学習日記 2026/02/25 Go言語BubbleTeaで「戦国大名」001

 さて、前回「戦国大名の説明書をNotebookLMに読ませてOCRで理解させ、Antigravityで質問できたらなぁ・・」なんて思って終わったのですが

・薄暗い部屋で説明書をスマホで1ページずつ撮影して・・

・NotebookLMで読み込ませると要約などが普通に可能だった

・NotebookLMによるとGoogleDriveに画像を置いてAntigravityで読めば良いと

・GoogleDriveに画像を置いたがAntigravityから認識するにはChromeを入れたり余計なソフトを導入する必要があった

・結局、コードを書いてるワークスペース(フォルダ)に置いてOCRで理解してくれと依頼したらローカルの画像を読み込んでOCRしてコンテキストとして使ってくれるようになった

 要するに「最高」って事だけど

 

 とまあ、1ターンが1年という仕様。やること多いからねぇ!

 

 戦闘よりも領地の経営に重きを置いてる感じ・・これはなかなか・・クロちゃんやりますねぇ!

 

 ソロシナリオなんかもあるんですよね。なのでCOMの思考などを考えなくても、とりあえず遊べるものには出来そう。

 ってことで、早速お楽しみの「構造体」作りを開始!と、思ったんだけど・・折角ルールを解析してもらってるんだから、必要な構造体を作ってもらうのも良いんじゃないか?AIのお手並み拝見って事で!

 

 GamePhaseをわざわざIntで定義するのか・・そしてConstって・・? =iotaにするのもちょっとよく分からんし質問せねば。

 何っ?GamePhaseに対してStringメソッドなるものを作って、PhaseをIndexにして文字列を返すだと・・なんでこんなややこしいことを・・

 

 続いて国と武将構造体だな。うーん、三国志で言うところの君主はIDで管理されるのか・・?君主にも能力値の違いがあると思うから君主構造体も必要な気がするんだけど・・武将構造体と項目は併用できるのかな?

 国同士のつながりには特に気を使ってくださいよ!とお願いをしておいたのだけど、それはNeighborsで行うらしい。String(でもID)のスライスでネットワークを表現できるのか・・

 

 あ、Player構造体がある。能力値の違いとか無かったかなぁ?

 GameStateは思ったよりシンプルだった。

 本当はここまでで良かったんだけど!なんかBubbleTeaで作りますのでImportとかそういうところまでは書いてくださいと言ったら、実際にBubbleTeaで最低限の動きをするところまで書くとか言い出すから始末に負えないよ!まあ、折角なので拝見しますけど

 

 なるほど、Id1の国のお隣にId2が存在するかをチェックするメソッドか

 

 あ〜IDって数字じゃなくてローマ字読みで管理するのか、たしかにユニークだもんな〜。なるほど・・多分、国が繋がってて補給路がどうのこうの・・ってネットワーク問題は出てこないような気がするけど、出てきたら・・探索をやらねばならんのだろうな(-_-;)

 

 で、こちらはMainのファイル。先程まではModels.goって事で構造体なんかをまとめておくファイルでした。

 で、ここでBubbleTea用のModel構造体。これはこっちで作るのか・・ひらがな麻雀では、このModelにGameStateも一緒くたにしてたけど、たしかにGameStateは別の構造体で内包するべきだったな。Curorって?

 

 あれ?さっき既にインスタンス作ってなかったか?と思ったら、あっちはどうも単純に構造体のサンプルを見せるって目的のためだけに書かれたものだったっぽい?逆にややこしい!

 

 あ、Cursorって国選択かなんかの表示用インデックスだったのか。抜かりがない!

 

 で、表示用の背景色などを変数で決めて・・前にも書いたけどVSCode系は、このサンプルカラーが出るのが強いよなぁ。Helixじゃあこうは行きませんよ

 

 で、表示部分。

 いや、確かに・・TUIならこれで最低限の表示は出来てるか〜。やっぱりTUIは作るには最高だな、シンプルで。

 

 あれ?またMainがある!だからエラーが出てたのか。まあ、そんくらいは勘弁しておこう、GeminiFlash2.5だし。

 というわけで、いきなり楽して始まったけど・・AI時代のホビープログラミングはこのくらいまで書いてもらってから始めるのが良いんじゃないの?という気もする。

 次回は(データを渡してなかったので当然なのだけど)抜けてる吉凶札、武将チップ、城チップなんかを手動で実装していくところから始めよう!

 

つづく

 

プログラミング学習日記 2026/02/24 ひら◯な麻雀エディタ版、完成

 全角文字を入力できるか?という質問に対してKiroの返答はYes。良かった・・

 うーん・・今まで入力状態で間違ってIME起動状態になってたんだけど、その場合はなんかうまくいかなかった感じなんだよなぁ・・このパターン1は普通に1文字ずつ入れていく仕様だしうまくいかないような?

 

 うーん、なんとなくこっちなら全角文字列の一気入力が出来そうな気がする?

 Modelに作ったフィールドに対して、TextinputライブラリのNewメソッドを渡して初期化。

 おそらく入力フィールドにPlaceholderに入れた文字列がうっすら表示される

 初期値としてYakuInputに入力のフォーカスが設定される

 文字数と何かのリミット。Widthとは?

 

 得点入力も初期値として同じような設定をして、こっちはフォーカスしないでおく、と?

 

 最初にTea.Cmd型のcmdを作っておいて

 役名入力PhaseではEnterとEsc以外の文字はCase無しでYakuNameInputに、む〜・・.Update(msg)ってどういうこと?再帰って事になるのかな?

 

 得点入力については・・Enterで役入力を終了.Value()メソッドで中身を文字列にして出力かな?

 ScoreはStrconvでIntに変換して出力、エラー対処はせずって感じで

 その後、YakuDicに追加

 YakuNameInput.SetValue("")で初期化

 それ以外の場合はScoreInputに対してYakuNameInputと同様の処理、と。

 ややこしいけど、まあ写経のノリで書けばいいか

 

 後は入力中の表示部分、と。まあ、とにかくやってみよう!

 

 分からなかった部分を質問。なるほど、Focusを外すのがBlurだ、と。

 

 .Update内なのにInput.Update(msg)ってもしかして再帰的な使い方をするのか?と思ったら、普通にTextInputに対するUpdateメソッドということで全くの別物でした。それなら分かりやすいから良し!

 

 というわけで全角文字列入力部分はほぼ写経だったけど実装完了。実行してみたがエラーがずらずらと出たのでデバッグを依頼する。AIにはもっともつまらない部分を任せるのだ。わざわざ「たくさんの」なんて書かれるくらいだから相当だなw

 

 基本的にはタイポばっかりだったのでハイハイ、って感じなんだけど、Agariメソッドは完全に失念していた。でも、これってエディタ版だと特に役目も無いね

 

 というわけで実験。テストなので適当な単語で良いんだけど、結構気にして頑張ってしまいました。そして思ったんだけど・・14枚で和了って微妙だな!頭として2文字の単語ってなぁ・・ということで、11枚配布で12枚和了の想定4単語って事にすべきかな、と。いや・・もう面倒だから親も子も12枚配布で12枚和了にしよう。なんちゃってだし

 

 あと、全部グループにしたところ、想定外の表示エラーが・・。それと単語や役がちゃんと辞書登録されたのかをチェックできないのも気持ち悪いので、単語・役の表示機能をつけよう。

 そんで、二人打ちにするところまではやろうかな・・単語や役の登録って事を考慮するとどう考えたって無地のカードでリアルに遊ぶ方が楽で楽しいからな〜。まあ、学習ネタとして面白そうだから手を出したってだけヨ。もはや心は「戦国大名」に飛んでしまってるだな〜

 

 というわけで微調整。パイの数は最初から12枚配牌、12枚和了にして

 

 辞書に登楼されてるかをチェックしたいので表示するように・・って、辞書からいてレートで取り出すってどうやって書くんだっけ?

 OK

 

 単語を登録したところ

 

 和了処理をしたので役も登録された。ただ、このTextinputは入力中のIME部分が不可視(理由は不明・・川の部分と同じ高さに入力UIが存在するからか?)なのでかなり使いにくい。どうしたもんかなぁ・・

 まあでもこれで一応エディタ部分は出来たと言ってもいいだろう。なぜならば別にこれを使って本当にゲーム可能なデータを作ろうとは思ってないから。FC版のドラクエ1もゴールドマンを倒せるくらいまでが面白くて、そこまでは何回もやってしまった・・ってのと似てるかな。これ以上作り込んで行っても(お金になるわけでもないし)幸福度は上がらない予感がするんですよねぇ・・

 

 というわけで、これがエポック社の名作(と噂の)ボードゲーム「戦国大名」だッ!ルールブックは薄いんだけど、なかなかに複雑っぽい。ザッと途中まで読んだところによると、合戦よりも金をばらまいての「影響力」の拡大がキモっぽい?

 

 ボードの代わりにこのバカでかい日本地図にコマを配置したりしてゲームが展開する模様。ちなみに、前の持主はコマは外してあったけど「吉凶札(毎月配られるイベント指示カード)」は1枚も台紙から外してなかったので、恐らく一度もプレイしてなかったと思われる。説明書も全く折り目や書き込みも無かったしね。まあ、このマップを見れば・・

 今回、ちょっと試しでスマホでマニュアルを撮影、OCRでAIに読み込ませてNotebookLMでルールのまとめと、構造体の作成をやらせてみようかな(構造体作成はなかなかに楽しいところなのでAIにやらせるのは惜しいが!)

 

 というわけで次回から「戦国大名」編に突入だー!