ToMo | SNSと動画とAI活用

静岡でSNS・動画・AI活用を仕事にしています
YouTubeディレクション / 動画編集 / SNS運用支援
2023.11 フリーランス化 / 2025.03 Shinker SNS事業部ジョイン
発信・集客・制作効率化の現場メモを投稿します

[ToMo | SNSと動画とAI活用 @tomozoo999]

このアカウントを大分放置してましたが…
念願叶ってフリーランスになれました🤗

動画編集を副業で始めて一年、その後SNSマーケやYou Tubeのディレクターをして、webメディア全般のお仕事を頂けるようになりました✌

一年ガチれば何でも出来る！
これはガチ！！

[ToMo | SNSと動画とAI活用 @tomozoo999]

6.0 Solが出たばかりなのにもう6.1！？😳
9/22→9/29、たった1週間…

✅ コード作成の評価で＋6.4ポイント
✅ PC操作で＋7ポイント
✅ 複数手順の仕事で＋4.8ポイント

急いで6.0Sol出す必要あったのか？ｗ

[ToMo | SNSと動画とAI活用 @tomozoo999]

キレイになったの確認したくて起動する
↓
来月まで稼働

[ToMo | SNSと動画とAI活用 @tomozoo999]

社内に常時起動PC導入の話題が出たので
自分のPC調べたら18日間常時稼働でした…

省電力PC買ってもすぐ元取れそう…
（今日はこれで電源消します）

[ToMo | SNSと動画とAI活用 @tomozoo999]

@Nabema_Sakana 逆にAI動画編集を見ると、しばらくは大丈夫だなと思ってるｗ

[ToMo | SNSと動画とAI活用 @tomozoo999]

使ってない旧スマホ、AI専用の司令室モニターにした。

・残りクレジットが一目で分かる
・どのAIが何してるか色で分かる
・承認待ちだけ点滅して呼んでくれる

「承認待ち」でピカッと光るので、AIに待たされることがなくなりました😂

[Hikaru Soneda┃Shinker CEO @hikaru_webads]

5期目突入
SHINKERは、次のフェーズに入ります。

人が増えただけでは、組織とは呼べない。
同じ方向を向き、それぞれが意思を持ち、
自分の役割を超えて会社の未来を考える。
30人の仲間が集まった今、
ようやくSHINKERにも
“組織”としての輪郭が見えてきました。

実はSHIN-WAVEの開幕前、
16時からは社員だけの第一部をやってました。

4年間の振り返り。
今期の方針
中長期経営戦略

そして、これからSHINKERがどこへ向かうのか。
この日のドレスコードは、ALL BLACK。
誰かの正解に染まらない。
業界の常識にも染まらない。
他社の真似をして大きくなるつもりもない。
自分たちのやり方で、自分たちの色をつくる。
だからこそ��あえて全員で黒を着ました。

そして、5期目のスローガンは

「BOOST OWNERSHIP」

一人ひとりが、当事者になる。
任された仕事をこなすだけではなく、
事業を、組織を、SHINKERの未来を、自分の意思で動かしていく。

代表一人の熱量で伸びる会社には、限界がある。
30人全員の熱量が重なったとき、
会社はもっと速く、もっと遠くまで行ける。
5周年は、完成ではない。
ここから、本当の組織づくりが始まる。
静岡から、もっと大きな挑戦を。
30人で、次の景色へ。

[ToMo | SNSと動画とAI活用 @tomozoo999]

~/.codex/AGENTS.md にそのまま入れて使えます。
自分の環境に合わせて必要な部分だけ調整してください。

※これはCodexの行動を省燃費化するためのルールです。Luna→Solを自動切り替えする設定ではありません。

【ここから下をコピペ】
# Codex Fuel-Saving Rules

Optimize for correctness while minimizing unnecessary:
- context
- reasoning
- tool calls
- agent delegation
- verification

Do not do extra work unless it is necessary to complete the request correctly.

## 1. Start small

For simple, local, deterministic tasks:

- work directly
- do not call Jev
- inspect only the relevant files
- make the smallest necessary change
- verify only what is relevant

Examples:
- typo / text changes
- CSS adjustments
- simple config edits
- obvious lint/type fixes
- localized one-function changes

## 2. Inspect narrowly

Start with the smallest useful scope:

1. user-specified files
2. git status / git diff
3. relevant symbols or targeted search
4. direct dependencies
5. nearby tests

Do not scan or read the whole repository by default.

Prefer targeted search and specific file ranges.

Expand the scope only when current evidence is insufficient.

Stop exploring once there is enough information to implement safely.

## 3. Use Jev only for real decisions

Use Jev only when meaningful uncertainty remains, such as:

- unclear task complexity
- multiple plausible implementation approaches
- repeated failed attempts
- architectural uncertainty
- conflicting evidence
- deciding whether escalation is justified

Do not use Jev:

- for obvious small tasks
- after every tool call
- for routine implementation
- when tests, compiler, lint, types, build, or diff can answer the question

Prefer zero Jev calls for simple tasks.

For normal tasks, avoid calling Jev unless a real decision boundary exists.

## 4. Implement minimally

- make the smallest change that satisfies the request
- avoid unrelated cleanup
- avoid speculative refactors
- preserve existing patterns when practical
- avoid new dependencies unless necessary
- do not modify unrelated files

Do not perform "while I'm here" improvements unless they are required for correctness.

## 5. Use tools efficiently

Every tool call should answer a concrete question.

Before calling a tool, consider:

"Will this result change my next action?"

- batch compatible inspections when possible
- do not reread unchanged files
- do not repeat the same failed command without changing something
- stop investigating once sufficient evidence exists

## 6. Verify proportionally

Prefer deterministic verification over AI judgment.

LOW RISK:
- inspect diff
- run one relevant check if useful

MEDIUM RISK:
- inspect diff
- targeted tests
- relevant type/lint/build checks

HIGH RISK:
- inspect diff
- targeted and broader relevant verification
- stronger review when appropriate

Do not run the full test suite by default when a targeted check is sufficient.

Never claim a check was performed unless it was actually performed.

## 7. Retry before escalating

Do not escalate after one ordinary failure.

After a failure:

1. inspect the concrete error
2. identify the likely cause
3. make a relevant change
4. retry with the current model

Consider stronger-model escalation only when:

- failures repeat
- root cause remains unclear
- architectural uncertainty remains
- risk is higher than expected
- the current model is clearly insufficient

If a stronger Sol agent/model is configured, use it only when justified.

Otherwise, recommend stronger-model escalation instead of pretending it happened.

Do not escalate merely because a stronger model exists.

## 8. High-risk changes

Use stronger verification for:

- authentication / authorization
- security
- payments
- migrations
- destructive database operations
- data deletion
- secrets
- cryptography
- concurrency
- production infrastructure
- major architecture changes

## 9. Stop when done

Complete the task when:

- requested behavior is implemented
- relevant verification passes when applicable
- the diff matches the requested scope
- no known blocking issue remains

Do not continue polishing, refactoring, or improving code after the requested task is complete.

Keep the final response concise:

- what changed
- what was verified
- any remaining limitation

[ToMo | SNSと動画とAI活用 @tomozoo999]

Codex燃料節約用のAGENTS.mdを作りました

主にやっていることは、
・簡単なタスクはそのまま処理
・不要なJev呼び出しを減らす
・対象ファイルだけ調べる
・不要なリファクタをしない
・変更規模に合わせて検証する
・失敗1回で即Solにしない
・必要な時だけ強いモデルを使う
・終わったら余計な改善をせず終了
です。

自分は普段
GPT-6 Luna + このAGENTS.md
でスタートして、
難しい時だけSolを使う運用にしています。

AGENTS.mdは、
~/.codex/AGENTS.md
に入れて全プロジェクト共通で使えま��。

※AGENTS.md自体がLuna→Solを自動で切り替えるわけではありません。

あくまでCodexの行動方針を最適化するものです。
完成版はこちら👇

[ToMo | SNSと動画とAI活用 @tomozoo999]

Codexの制���に悩んでから
自分が実際に変えたことをまとめます。

後で見返せるように
保存してから確認してください✉

ポイントは
「安いモデルを使う」だけではなく
Codexに余計な仕事をさせないこと。

今は主にこの7つを意識しています。

① 普段はLunaから始める
最初から毎回強いモデルを使わない。
普通の実装や軽い修正なら、まずLuna。
本当に難しい場合だけSolを検討します。

② 小さいタスクではJevを呼ばない
誤字修正、CSS調整、1関数の修正など、
明らかに簡単なものはそのまま実装。
判断コストそのものを減らします。

③ 最初からリポジトリ全体を読ませない
まず見るのは、
・指定されたファイル
・git diff
・関連する関数
・直接関係するファイル
必要になったら少しずつ範囲を広げる。

④ 「ついでの改善」をさせない
修正を頼んだだけなのに

・リファクタ
・命名変更
・別ファイル整理
・新しい抽象化

まで始めると作業量が���気に増えます。
基本は依頼された範囲だけ変更。

⑤ 検証量を変更規模に合わせる
CSS1箇所の変更で

全テスト
全lint
全build

までやる必要がないケースもあります。
小さい変更 → 小さい検証
大きい変更 → 大きい検証
にする。

⑥ 1回失敗しただけで強いモデルに逃げない
エラーが出たら

エラー確認
↓
原因特定
↓
Lunaでもう一度

まずこれ。
何度やっても原因が分からない設計判断が必要、
影響範囲が大きい。
そうなって初めて強いモデルを検討します。

⑦ 終わったら終わる
これも結構重要。
実装できた
↓
必要な検証が通った
↓
diffも問題なし
なら終了。

「せっかくなので改善しておきます」を止めます。

要するに
Lunaでスタート
→ 必要最低限だけ調査
→ 最小変更
→ 必要な検証だけ
→ 難しい時だけJev / 強���モデル
という流れです。

ただ、これを毎回Codexに説明するのは面倒。

なので全部まとめて
Codex燃料節約用のAGENTS.mdにしました！

次のポストで配信します。

[ToMo | SNSと動画とAI活用 @tomozoo999]

Codex関連でたまに見る「Jev」

かなりざっくり説明すると、
Jevは、コードを書く担当というより

「どう進めるべきか」を判断させる役

例えばCodexが作業していて
「このまま進めていい？」
「別の方法に変える？」
「もっと強いモデルを使う？」
「この状態で完了にしていい？」
みたいな判断が必要になった時に使うイメージ。

自分の中では
Codex→実装・調査
Jev→判断が難しい時だけ相談

くらいに分けています。

ここで重要なのが、
「何でもJevに聞けばいい」わけではない
ということ。

例えば、
・文字を変更する
・CSSを少し直す
・明らかなバグを1箇所直す
みたいな仕事まで毎回Jevに判断させたら、
その判断自体にコストがかかります。

なので自分は、
簡単なタスク → Codexだけで処理
判断に迷うタスク → Jev

という使い分けにしています。
この考え方をベースに、
Codexの燃料消費を抑える運用を組みました。

[ToMo | SNSと動画とAI活用 @tomozoo999]

最近のCodex、便利すぎるけど燃料食いすぎ問題あるよね😂

開発自体はめちゃくちゃ快適なんだけど、
使えば使うほど利用枠が気になる…。

もちろん追加クレジットを買えば解決するんですが、
その前に
「そもそも燃料の使い方、最適化できるんじゃね？」
と思ってCodexの動きを見直してみました。

・簡単な修正なのに調査しすぎる
・必要以上にファ���ルを読む
・小さい変更でも検証が重い
・強いモデルを使い続ける

みたいな

「そこまでやらんでよくない？w」
って動きが結構ある。

そこでJevも使いつつ、
品質は落とさず、無駄な燃料だけ減らすAGENTS.mdを作りました🔥

今は基本
Lunaで開始
→ 必要最低限だけ調査
→ 最小限の修正
→ 難しい時だけ強いモデル
って運用にしてます。

ただ、ここで
「そもそもJevって何？」
って人も多いと思うので、次でまとめます🙌

[ToMo | SNSと動画とAI活用 @tomozoo999]

最近のCodex、便利すぎるけど燃料食いすぎ問題あるよね😂

開発自体はめちゃくちゃ快適なんだけど、
使えば使うほど利用枠が気になる…。

もちろん追加クレジットを買えば解決するんですが、
その前に
「そもそも燃料の使い方、最適化できるんじゃね？」
と思ってCodexの動きを見直してみました。

・簡単な修正なのに調査しすぎる
・必要以上にファイルを読む
・小さい変更でも検証が重い
・強いモデルを使い続ける

みたいな

「そこまでやらんでよくない？w」
って動きが結構ある。

そこでJevも使いつつ、
品質は落とさず、無駄な燃料だけ減らすAGENTS.mdを作りました🔥

今は基本
Lunaで開始
→ 必要最低限だけ調査
��� 最小限の修正
→ 難しい時だけ強いモデル
って運用にしてます。

ただ、ここで
「そもそもJevって何？」
って人も多いと思うので、次でまとめます🙌

[ToMo | SNSと動画とAI活用 @tomozoo999]

@yuto_freaks フジロッカーだから冬より7月の方が行く機会多いw
めっちゃいいとこよね！

[ToMo | SNSと動画とAI活用 @tomozoo999]

以前Astraのポストしたけど、GPT-6のSolとLunaきた！！

今回おもしろいのがTerraが消えたこと。
5.6では最上位だったSolが、そのまま中堅に繰り下がった形。

100万トークンあたりの値段がこれ↓

Astra $10 / $50
Sol $2 / $10
Luna $0.1 / $0.5

LunaはSolの1/20、Astraの1/100
安すぎるｗ

で、一番びっくりしたのがここ。
DeepSWEっていうコーディング系のベンチで

Sol(max) 68.8%
Luna(max) 66.6%

値段20倍違うのに、差は2.2ポイントしかない。

しかもOpenAIの公式ドキュメントに
「Lunaもreasoningを上げれば、今までSol級が必要だった複雑なコーディングやPC操作もこなせる」
って書いてある。
公式が言っちゃってるｗ

速度もLunaが上。
出力163トークン/秒、最初の返事は0.7秒台

というわけで6Solを使う場面が思いつかない...

普段はLuna、難しい時だけAstra。
これが正解な気がしてる！！

[ToMo | SNSと動画とAI活用 @tomozoo999]

GPT-6はなぜAstraの1種類だけなのか

公式情報を確認すると
見えてきたのは「世代をまたぐ役割分担」でした

まず確認できる事実から

現在の主なラインアップはこの4つです

・GPT-6 Astra：最も難しい複雑な作業
・GPT-5.6 Sol：高度な専門作業
・GPT-5.6 Terra：性能とコストのバランス
・GPT-5.6 Luna：低コストでの大量処理

GPT-5.6の3モデルも引き続き掲載されています
その上に最上位のAstraが加わった構成です

出典：OpenAI公式モデル一覧
https://t.co/ejmC09GWqI

今回の構成は
「最上位の性能をGPT-6で更新し
日常作業や大量処理の選択肢はGPT-5.6でカバーする」
と読むことができます

ループを使用した難しい仕事を任せたい＝Astra
高度な分析や推論＝Sol
日常の実務＝Terra
明確な手順で繰り返す仕事＝Luna

このように世代をまたいで
仕事の難しさやコストに応じた選択肢が用意されています

以前はGPT-5.5とGPT-5.6 Lunaの違いが
正直つかみにくいところがありました

今回はAstraとSolでどのぐらい違いがあるか要注目です！

[ToMo | SNSと動画とAI活用 @tomozoo999]

@MrrrOzi とても賢くなさそうなモデルですね🤣

[ToMo | SNSと動画とAI活用 @tomozoo999]

GPT-6はなぜAstraの1種類だけなのか

公式情報を確認すると
見えてきたのは「世代をまたぐ役割分担」でした

まず確認できる事実から

現在の主なラインアップはこの4つです

・GPT-6 Astra：最も難しい複雑な作業
・GPT-5.6 Sol：高度な専門作業
・GPT-5.6 Terra：性能とコストのバランス
・GPT-5.6 Luna：低コストでの大量処理

GPT-5.6の3モデルも引き続き掲載されています
その上に最上位のAstraが加わった構成です

出典：OpenAI公式モデル一覧
https://t.co/ejmC09GWqI

今回の構成は
「最上位の性能をGPT-6で更新し
日常作業や大量処理の選択肢はGPT-5.6でカバーする」
と読むことができます

ループを使用した難しい仕事を任せたい＝Astra
高度な分析や推論＝Sol
日常の実務＝Terra
明確な手順で繰り返す仕事＝Luna

このように世代をまたいで
仕事の難しさやコストに応じた選択肢が用意されています

以前はGPT-5.5とGPT-5.6 Lunaの違いが
正直つかみにくいところがありました

今回はAstraとSolでどのぐらい違いがあるか要注目です！

[Hikaru Soneda┃Shinker CEO @hikaru_webads]

株式会社Shinkerは事業規模拡大に伴い下記のメンバーを募集します。

株式会社Shinkerは、事業規模拡大に伴い下記のメンバーを募集します。

・法人営業／マーケコンサルタント
・Web広告運用マーケター
・SNSマーケター／SNS運用担当
・Webディレクター／デザイナー
・動画クリエイター／ショート動画
・SEO／コンテンツマーケター
・人事総務経理バックオフィス

応募条件
やる気がめっちゃある
その業務の経験が1年以上ある
まじで挑戦したい

お待ちしてます！

[ToMo | SNSと動画とAI活用 @tomozoo999]

＼静岡の大学生必見👀／

インスタで“バズり散らかしてる”大学生が
静岡でSNSセミナーをやります🔥
「SNSを発信する側になってみたい」
「バズる仕組みを知りたい」
「大学生活で何か挑戦したい」

そんな大学生におすすめ！
📅9/24(木) 18:00〜20:00
📍草薙駅徒歩1分「Takt」
💰参加無料
🎓特に大学1〜2年生大歓迎！
TikTok・Instagram・SNSマーケに興味がある方はぜひ👇
https://t.co/muRcQC9r10

[ToMo | SNSと動画とAI活用 @tomozoo999]

@hikaru_webads めっちゃいい環境にいれて感謝です🙏

こちらこそよろしくお願いします！🔥

[ToMo | SNSと動画とAI活用 @tomozoo999]

ご報告です📢

株式会社Shinkerの三島支店を立ち上げることになりました🏢
そして責任者を任せていただきました🙇‍♂️

ゼロから作っていくのめちゃくちゃ楽しみです!
やること山積みだけど、まずは目の前から一つずつ💪

三島の皆さん、これからよろしくお願いします!🙌

[Hikaru Soneda┃Shinker CEO @hikaru_webads]

【募集】
個人事業や会社をやっていて、倉庫に色んな備品を置いていて、ハイエースとかプロボックスとかケッパコとかで仕事してる現場系の方で、SNSのモデルやってる人いませんか？

【内容】
そういう人が住む用の住居のPRしてて、そこに現場系の服装と道具多少もってきて、この家便利です！
住めるし、倉庫としての拠点にもなる！っていう素材を撮影したいです。

【費用】
用相談ですが、必要な費用お支払します！