YOSSII

#CEO #ITコーディネーター #公的機関のAI専門家 #公的機関のDX専門家 #ウサコン #Saas

[YOSSII @Yoshi812001]

【ウサコン】🐰 本日リリースしました！

AIがあなたの会社のDXコンサルタントに。

「うさぎコンサルティング」は、
ITコーディネーターの知見 × 生成AIで
中小企業のデジタル経営を月額7万円で伴走支援します。

✅ 変革認識分析
✅ 成熟度評価
✅ デジタル戦略策定

まずは詳細をご覧ください👇
https://t.co/U2Di2d3cvN

[YOSSII @Yoshi812001]

今日の記事です。

https://t.co/9SLiV6bPr2

[YOSSII @Yoshi812001]

ダン・コーの理論をAIエージェントで実践中です。 https://t.co/13fyLoA7mn

[yusei @yusei_ai]

最近の実装フローはこれ。

・Claudeで壁打ちして、アイデアや問題点を洗い出す
壁打ち結果を整理する
・GPT-5.6 Sol Proで、より完成度の高い設計書にする
その設計書をGPT-5.6 Sol xhigh（Codex）に渡して実装させる
AIを1つに任せるより、役割分担した方がかなり安定する。

[YOSSII @Yoshi812001]

公的機関でコンサルタントをしているんだけど、大抵気に入られる。それは自慢でもなんでもなくてAIに詳しいというブーストがかかっているだけ。

今日はそのブーストがMAXに機能した。
公的機関経由だから無料でコンサルしてるのに、民間で有料でもいいから継続契約して欲しいとのことでした。

仕事が無くて苦しいタイミングでいつもこういうことが起きるのが不思議です。

[YOSSII @Yoshi812001]

なんか今めんどくさいと思っている開発フローを丸ごと解決する予感。

[yusei @yusei_ai]

OpenAIが「Symphony」を公開。

GitHub IssuesやLinearからタスクを拾って、
仕事ごとにCodexを起動し、
実装・テスト・PR作成まで自動で進める仕組み。

簡単に言うと、
「AIエンジニアたちに仕事を振る監督役」。
なかなか面白そう
https://t.co/2DNIPVnrHC

[うし部長 @ushi_butyo]

管理職をしてると「こいつ、マジか」と若手への信頼が一気に揺らぐ瞬間がある。「ミスが多い」「仕事が遅い」「報告が苦手」「要領が悪い」これだけで信頼がなくなるわけやない。新人なんて、分からんことも多いし、失敗して当たり前やから。でも、ミスした時の一言で「あ、この子ちょっとないな」と思うことがある。それが、

[YOSSII @Yoshi812001]

CodexのRecord a skillってどこにあるんだろーと思ったらChatGPTに切り替えてからプラグイン検索でRecord & Replayってやつをインストールしないといけないのね。2重の罠。

[YOSSII @Yoshi812001]

理解が追いつかないが、すごい発想！！

[mana｜株式会社MakeAI CEO @MakeAI_CEO]

ちょっとちょっとちょっと待って！！！Codexエグすぎる！Codexに「Record機能あると思うんだけど、なんの作業をSkill化したらわからないから、適当にあなたが自分自身を動かして、適当に録画してきてSkills作って。そしてその収録動画を編集して、Xで見せやすくして」って言ったら、自分で録画から撮影してきてびびったw

[YOSSII @Yoshi812001]

gpt-5.6は忠実に実行する機械って感じだな。
扱い方をマスターできれば強いけど操作方法を覚えるのが大変って感じ。
だから操作をFable5に任せている。

[YOSSII @Yoshi812001]

@Tono_Ken3 GMKtec EVO2 128GBはあるんですけどねー！経費で買える余裕ができるように頑張ります🤣

[YOSSII @Yoshi812001]

おめでとうございます！
わたしもローカルでそのような仕組みまで到達したい！

[TonoKen3🏯Local LLM&Infrastructure Architect🚀とのけん @Tono_Ken3]

コーディングは変わった

フロンティアモデルの設計不備をたった120Bパラメータのローカルモデルが見つけて補完する

コーディングは変わった

今日からだ

これまでの投資に対する爆発的なリターンが還ってきている実感がある

[YOSSII @Yoshi812001]

仕事が全然無いのに人を雇用した。
資金は急激に減っていく。。
でも、ビジョンは10人以上の企業にして、
安定した会社にしたいからビジョンからは外れていない。
人手不足の時代に良い人材が来たなら雇用するべき。心はそういっているから。
でも、資金的には雇用するべきではない。
この葛藤。

仕事ください。

[YOSSII @Yoshi812001]

事業主の方向けですが、
変革を意識されていましたら
ウサコンは手助けになると思います

https://t.co/zm5Obg0XU1

[YOSSII @Yoshi812001]

もう人間のサーバー管理者いらないね。

[yusei @yusei_ai]

最近物騒だから、AIにサーバー管理を任せてみた。
✔ 不正SSHログインを検知
✔ 怪しい通信を監視
✔ 危険なら自動でブロック
✔ Discordへ即通知
✔ DMからサーバーの状態も確認可能
AIが24時間見張ってくれるから、人間は寝てても安心。
しかもCodexで作りました。
#自宅サーバー #AI #Codex

[YOSSII @Yoshi812001]

事業主の方向けですが、
変革を意識されていましたら
ウサコンは手助けになると思います

https://t.co/zm5Obg0XU1

[YOSSII @Yoshi812001]

アプリ開発って終わりが無いよね。
ずっと不具合修正とブラッシュアップがつづく

[yusei @yusei_ai]

GPT-5.6 solは使っててFableよりも使い勝手のいいAIって感じ
/goalで放置したら勝手に指示した内容が終わってるし
skillを改善していくうちにどんどんAIが賢くなっていくから
GPT-6はどんなAIになるのか楽しみだよね

[YOSSII @Yoshi812001]

GPT-5.6で一番気に入っているのは、コード生成の速さではなく、長い開発工程を最後まで崩さず進められること。

私の環境はWindows 11＋PowerShell。
TypeScript / Python、React / Next.js / Vite / Electronを中心に開発しています。

GPT-5.6には、AGENTS.md、100種類以上のカスタムスキル、hooks、MCP、長期メモリ、複数エージェントを連携。
普段は、目的と完了条件を渡すと、
要件整理
→既存コード調査
→実装計画
→コーディング
→テスト
→レビュー対応
→PR作成
まで進めてもらいます。
特に得意なのは、複数ファイルにまたがる改修、障害の根本原因調査、CI修正、GitHub Issueの実装です。
以前は人間が工程ごとにAIへ指示していました。
今はGPT-5.6が開発の司令塔となり、人間は目的・優先順位・最終判断に集中できます。
私にとってGPT-5.6は「コードを書くAI」ではなく、検証可能な成果まで一緒に仕事を進める開発パートナーです。

#OpenAI #AI駆動開発 #生成AI #プログラミング

[Tibo @thsottiaux]

Or… what if we gave you $100 in Codex credits if you tell us what you love about GPT-5.6 Sol or why you switched?

Tweet it, claim your gift, enjoy more usage. First 10k get the free tokens!

https://t.co/8mU93eA13i

[YOSSII @Yoshi812001]

なんでも推論MAXにすれば良いってもんじゃないことに気が付いたので、

OpenAI社の人たちの使いかたを参考にしつつ、
以下の構成をおすすめします。

# 高速実装チーム：モデル役割分担

普段は速度を優先し、設計判断とレビューだけ推論強度を上げます。

## ☀️ Sol：司令塔

- **推論強度：** `high`
- **同時数：** 1
- **担当：**
- 目的と受入条件の確定
- タスクの分解と割当
- 優先順位と実行順序の決定
- 意見が割れたときの裁定
- 最終的なGo／No-Go判断
- **原則やらない：**
- 日常的なコード探索
- 定型的な実装
- 大量ログの読み込み

## 🌍 Terra Manager：計画・調査

- **推論強度：** `high`
- **同時数：** 1
- **担当：**
- コードベースの調査
- 依存関係と影響範囲の確認
- 実装計画の作成
- Lunaに渡す作業範囲の確定
- テスト方法と完了条件の定義
- **原則やらない：**
- 自分が作った計画の最終承認
- mainブランチや本番環境の変更

## 🌙 Luna Builder：高速実装

- **推論強度：** `medium`〜`high`
- **同時数：** まず2、安定後は最大4
- **担当：**
- 仕様が固まった小さな実装
- テストコードの追加
- 関連テストの実行
- 変更内容と未解決事項の報告
- **実行ルール：**
- 1タスク＝1 worktree
- 1ファイル＝1担当
- 共有ブランチを直接変更しない
- **原則やらない：**
- 仕様変更
- アーキテクチャ判断
- 担当外ファイルの変更

## 🔍 Terra Reviewer：独立レビュー

- **推論強度：** `max`
- **同時数：** 1
- **担当：**
- 仕様と差分の照合
- バグ、回帰、テスト漏れの確認
- セキュリティと保守性の確認
- 統合可能かの判定
- **重要ルール：**
- Terra Managerとは別セッションで実行
- 実装者の結論を引き継がない
- レビュー中に自分でコードを修正しない
- 修正はLunaへ差し戻す

## 🛡️ Sol Reviewer：高リスク裁定

- **推論強度：** `max`
- **起動条件：**
- 認証
- 決済
- データベース
- セキュリティ
- 大きなアーキテクチャ変更
- 同じ問題で複数回失敗した場合
- **担当：**
- Terraのレビュー結果を再評価
- 高リスク変更の最終Go／No-Go判断

## リスク別ルーティング

### 低リスク

例：文言修正、テスト追加、局所的なUI修正

- 実装：`Luna / medium`
- レビュー：`Terra / high`
- 最終判断：`Sol / high`

### 中リスク

例：通常機能、複数ファイルの変更

- 実装：`Luna / high`
- レビュー：`Terra / max`
- 最終判断：`Sol / high`

### 高リスク

例：難しいバグ、共通API、アーキテクチャ変更

- 計画・実装支援：`Terra / high〜max`
- レビュー：`Terra / max`
- 最終判断：`Sol / max`

### 最重要

例：認証、決済、DB、セキュリティ、本番影響

- 実装：`Terra / max`
- 独立レビュー：`Terra / max`
- 最終裁定：`Sol / max`
- mainマージ・本番反映：`人間承認`

## 標準フロー

1. `Sol / high` が目的と受入条件を確定
2. `Terra Manager / high` が調査・分解
3. `Luna / medium〜high × 2〜4` がworktreeで並列実装
4. 各Lunaがテスト結果と差分を提出
5. `Terra Reviewer / max` が独立レビュー
6. `Sol / high` が統合可否を判断
7. 高リスク案件だけ `Sol / max` で追加レビュー
8. mainマージ・本番反映は人間が承認

## 基本方針

- 親スレッドは原則 `Sol / high`
- 全モデルを常時`max`にしない
- 速度はLunaの並列実装で稼ぐ
- 品質はTerraの独立レビューで守る
- 難しい判断だけSolを`max`へ上げる
- 実装者とレビュー担当を同じセッションにしない
- 検証結果がない変更は完了扱いにしない

参考：
https://t.co/ljwnPTpST7

[YOSSII @Yoshi812001]

なんでも推論MAXにすれば良いってもんじゃないことに気が付いたので、

OpenAI社の人たちの使いかたを参考にしつつ、
以下の構成をおすすめします。

# 高速実装チーム：モデル役割分担

普段は速度を優先し、設計判断とレビューだけ推論強度を上げます。

## ☀️ Sol：司令塔

- **推論強度：** `high`
- **同時数：** 1
- **担当：**
- 目的と受入条件の確定
- タスクの分解と割当
- 優先順位と実行順序の決定
- 意見が割れたときの裁定
- 最終的なGo／No-Go判断
- **原則やらない：**
- 日常的なコード探索
- 定型的な実装
- 大量ログの読み込み

## 🌍 Terra Manager：計画・調査

- **推論強度：** `high`
- **同時数：** 1
- **担当：**
- コードベースの調査
- 依存関係と影響範囲の確認
- 実装計画の作成
- Lunaに渡す作業範囲の確定
- テスト方法と完了条件の定義
- **原則やらない：**
- 自分が作った計画の最終承認
- mainブランチや本番環境の変更

## 🌙 Luna Builder：高速実装

- **推論強度：** `medium`〜`high`
- **同時数：** まず2、安定後は最大4
- **担当：**
- 仕様が固まった小さな実装
- テストコードの追加
- 関連テストの実行
- 変更内容と未解決事項の報告
- **実行ルール：**
- 1タスク＝1 worktree
- 1ファイル＝1担当
- 共有ブランチを直接変更しない
- **原則やらない：**
- 仕様変更
- アーキテクチャ判断
- 担当外ファイルの変更

## 🔍 Terra Reviewer：独立レビュー

- **推論強度：** `max`
- **同時数：** 1
- **担当：**
- 仕様と差分の照合
- バグ、回帰、テスト漏れの確認
- セキュリティと保守性の確認
- 統合可能かの判定
- **重要ルール：**
- Terra Managerとは別セッションで実行
- 実装者の結論を引き継がない
- レビュー中に自分でコードを修正しない
- 修正はLunaへ差し戻す

## 🛡️ Sol Reviewer：高リスク裁定

- **推論強度：** `max`
- **起動条件：**
- 認証
- 決済
- データベース
- セキュリティ
- 大きなアーキテクチャ変更
- 同じ問題で複数回失敗した場合
- **担当：**
- Terraのレビュー結果を再評価
- 高リスク変更の最終Go／No-Go判断

## リスク別ルーティング

### 低リスク

例：文言修正、テスト追加、局所的なUI修正

- 実装：`Luna / medium`
- レビュー：`Terra / high`
- 最終判断：`Sol / high`

### 中リスク

例：通常機能、複数ファイルの変更

- 実装：`Luna / high`
- レビュー：`Terra / max`
- 最終判断：`Sol / high`

### 高リスク

例：難しいバグ、共通API、アーキテクチャ変更

- 計画・実装支援：`Terra / high〜max`
- レビュー：`Terra / max`
- 最終判断：`Sol / max`

### 最重要

例：認証、決済、DB、セキュリティ、本番影響

- 実装：`Terra / max`
- 独立レビュー：`Terra / max`
- 最終裁定：`Sol / max`
- mainマージ・本番反映：`人間承認`

## 標準フロー

1. `Sol / high` が目的と受入条件を確定
2. `Terra Manager / high` が調査・分解
3. `Luna / medium〜high × 2〜4` がworktreeで並列実装
4. 各Lunaがテスト結果と差分を提出
5. `Terra Reviewer / max` が独立レビュー
6. `Sol / high` が統合可否を判断
7. 高リスク案件だけ `Sol / max` で追加レビュー
8. mainマージ・本番反映は人間が承認

## 基本方針

- 親スレッドは原則 `Sol / high`
- 全モデルを常時`max`にしない
- 速度はLunaの並列実装で稼ぐ
- 品質はTerraの独立レビューで守る
- 難しい判断だけSolを`max`へ上げる
- 実装者とレビュー担当を同じセッションにしない
- 検証結果がない変更は完了扱いにしない

参考：
https://t.co/ljwnPTpST7