今井翔太 / Shota Imai@えるエル
@ImAI_Eruel

これはどこかで別に長めに書きたいんですが、Deep
Seekの直近の論文などの研究動向を見ると、近いうちに出るとされるDeepSeek V4はかなり根本的なアーキテクチャ変更をやってくるような気がしています。Transformer丸ごととは言わないまでも、ChatGPT以降では最大のレベルで、また騒ぎになるのでは

ずっと続いてきたTransformer一強の状況が、一部とはいえ終わるってのは中々ヤバそうね

あとは、まあいつも通りOpenAI、Google、Anthropicの三社は性能レースをするだろうけど、OpenAIの資金繰りが中々厳しいという話も出ている。大丈夫だろうか

OpenAIは2027年半ばまでに資金枯渇、金融アナリストが大胆予想

https://gadget.phileweb.com/post-117234/

2.画像

正直nano-banana Proがレベル90くらいの感触であらゆることができてしまうので、性能向上よりかは、ローカル・エロ OK・オープンソースになった同性能品の出現に期待

3.映像

現状はしょうもない映像の生成に使われるおもちゃだが、今後はマジで面白いコンテンツを完成させるような野心あるクリエイターが出てくるかもしれない。

(一部の人から「一緒にすんな！」と怒られてしまいそうだが)初音ミクも当初はインターネットおもちゃくらいに考えてる人が多かった印象だが、結果的に多くのクリエイターを生み出したわけだし

あるいはロボティクスやコンピュータビジョンなどの実用性のある分野でも活躍しそう

あと、前項でも書いたが、何よりエロである。Sora 2レベルのエロ映像 AIが出たら、AV 業界が揺らぐかもしんない

Permalink | 記事への反応(0) | 22:31

■[日記]

今日は休み

昼過ぎに起きてだらだら掃除を2時間くらい

部屋の奥のほうのすのこのしたとかホコリがめっちゃたまってた

数か月単位で掃除してないからなあ

でもまだごみを捨てるフェーズから抜け出せてないなあ

それが終わったらごみじゃないものの処分でそれが一番時間かかるからなあ・・・

閑話休題

んで掃除一段落したからセルフカットして、1週間ぶりンシャワー浴びて、洗濯した

スーパーで半額の和菓子とか買った

ほんとはバニラ最中ジャンボとチョコモナカジャンボ買いたかったけどレジすげー並んでたから我慢した

あとバナナも半額だったから買った

半額でも１５０円する、お高めのバナナ

帰ってバナナ食べながら洗濯物干して、

スパゲッティ５００ｇとレトルトカレー3袋ゆでてたべた

れとるかれー、いわゆるホテルカレー的なやつ、具がマジでしょぼい

じゃがいもくらいで肉がない

ただのカレールウとかしただけよりかはマシな感じはするけどほんま侘しいわ

でもかといってスパゲッティのレトルトソース買うとめっちゃ高いんだよなあ

冷凍パスタ買ったほうが安いレベルだもん

100円で買えた時代はよかったなあ

hachiだっけ　メーカー

ふと研修の課題の締め切りが気になったけど、前回と違って直前までOKだった

もし前回と同じく研修の４８時間前までだったらあと1時間くらいで出さないといけないとこだった

スパゲッティ５００はさすがにおなかいっぱいになるなあ

その前にでっかいバナナも4本食ってるし

1食で食いすぎだな

和菓子とかは全部お預けにした

明日は早く行って研修の課題とか仕事を少しでもやりたいな

Permalink | 記事への反応(0) | 21:47

■anond:20260119182030

ネットで一日中レスバするような性格でないならなんでもOKやで

Permalink | 記事への反応(1) | 18:25

■中革連に対抗して、

核保有 OKを党是にする核マル連っていうのはどうだろう。

Permalink | 記事への反応(0) | 16:51

■自民党・裏金＆維新の会・社保のがれ

え？もう済んだことになってるんですか？

国民のみなさんはOK!ってなってるんです？

俺はなっていませんけど

こちらは生活が死ぬほど社保税金払ってるのに、そんなやつらは二度と政治に関われないのが当たり前じゃないですか

Permalink | 記事への反応(0) | 13:50

■spec 駆動開発の流れ、自分はだいたいこんな感じでやってるんだけど、これであってるのかなぁ？

CLAUDE.md や rules / skills みたいな形で、重要なコーディングルールはあらかじめかなり固めておく。

たとえば repository 層や Entity 層は具体的にどう書くのか、テストケースはどういう書き方をして、どういう観点で項目を洗い出すのか、みたいな AI への指示は最初から用意しておく。

あと、linter や ArchUnit、dependency-cruiser みたいなアーキテクチャ制約も、自分なりの定石を持っておく。

割と過剰なレベルでガチガチに固める感じで、アーキテクチャルールも「◯◯は XXX に依存できない」みたいなブラックリスト式じゃなくて、「◯◯は XXX だけに依存できる」みたいなホワイトリスト式の方が良いと思っている。

ts 前提だと eslint や tsconfig は一番厳しい水準に設定する、流石にきつい部分でてきたらそこだけ緩める、という運用

おすすめなのは、何かしらの小規模案件や個人開発アプリを1つオーバーエンジニアリング上等でガチガチ構成で作っておく。

そこで出てきた linter 設定やプロンプト設定を、別案件に横展開する感じ。

正直、ガチガチすぎると MVP とかレベルだとコード量は増えるけど、メンテする前提の案件ならバイブコーディング時代だと普通にペイすると感じている。

まずは仕様書作りから入る。

アイディアを思いついたら、AI と壁打ちしながら仕様を洗い出していく。

手書きでドメイン図を書いて、それを写メ撮って画像認識で仕様整理、みたいなのも割とアリだと思っている。

どういう画面があって、どういう入力項目や表示項目が存在するか、バックエンドはどういうエンドポイントが必要か、この辺りは最初に一通り洗い出しておく。

それに加えて、ユーザーが初めてトップページを開いてから登録・ログインして実際にサービスを一通り使うまで、みたいな流れをそのまま Playwright のシナリオテストに落とせそうな形で何パターンか仕様書にしておく。

全体の仕様書としては、あまり細部まで踏み込まない。

大枠が共有できていれば OK というスタンス。

開発に入ったら、最優先はドメインオブジェクトの作成。

ここは最重要だと思っているので、あまり作業を並列化しない。

フロントエンドで、DDD における集約みたいな概念がそのまま当てはまらない領域についても、設計時点で洗い出せているなら Entity 的なものやドメインサービス的なロジック用のレイヤを作って、ドメインオブジェクトとして実装していく。

最初に作った基本設計をベースに、◯◯Entity、XXEntity、△△Entity……を作るためのプランとチェックリスト形式の TODO を 1つの md ファイルに吐き出してもらう。

フェーズごとにフォーマッタ、linter、アーキテクチャルールなど一括実行したコマンド実行させて失敗してたら成功するまで修正繰り返させる。

ある程度わかりやすい単位で AI に依頼する感じで、出来上がったコードをレビューする前提なので、実装プランの md 自体はよほど分かりやすいツッコミどころがない限り細かくレビューしない。

mdのフォーマットは skills 側で事前に用意しておく。

フロントエンド用、バックエンド用の両方でドメイン層のファイルを作る。

当然、足りないロジックは後から絶対に出てくるけど、最初から完璧は目指さない。

TODO 一覧の中から自分の認知負荷が許す単位で「チェックリストのここからここまで実装して」と指示を出し、実装が終わったら TODO 項目のチェック状態を更新してもらう、md ファイルもコミットに含める。

コミット前にはlint ルールを無効化していないか、意図通りの実装になっているかは git diff の差分で必ず確認する。

ドメイン層の実装が終わったら、そこからは並列で進める。

git worktree を使うことが多い。

よくやるのはフロントエンドの画面モック作成とバックエンド実装の2並列で行う。

3並列以上はまだ自分の脳みその性能が追いついていない。

フロントエンドも当然 spec 駆動前提。

実装プランを考えてもらうときは「◯◯画面を実装プラン考えて」くらいの単位で依頼する。

実装プランの md ファイルを作るときのプロンプトには、基本設計の〇〇画面の項目一覧をベースに、◯◯のアイテムコンポーネント、リストコンポーネント、◯◯のボタンコンポーネント、Information コンポーネント、外部通信用の ◯◯Gateway を実装する、◯◯コンポーネントは既に ◯◯ 機能で実装してあるからそれを使って、◯◯は処理が膨らみそうだからドメインサービスで実装して、みたいな感じで頭の中のふんわりしたイメージを伝える。

詳細な名前とかは、AIにいい感じに考えてもらう。

バックエンドも同様で、◯◯のエンドポイントを作って、Gateway がこれこれ必要だから実装して、これはインターフェースと実装分けてね、Entityへの変換処理は関数分けて、◯◯の処理は Usecase 層で、◯◯の処理はドメイン層で、Usecase が膨らみそうだから ◯◯ の処理は独立したクラスにして、あ、似たようなのが ◯◯ 機能にあるからそれを参考にして、くらいの粒度で指示を出す。

フロントエンドの実装を待っている間に、バックエンドのプランを考えたり、タスク粒度を調整したり、リファクタリングプランを考えたりする、またバックエンドのAI待ち時間はフロントエンドのことをする。

フロントエンドオンリーの実装とかで作業が競合するリスクあるときは並列作業しない。

チェックリスト更新が終わるごとに差分を確認して、問題なければコミットメッセージを提案してもらってコミットする。

コミット粒度はあまり細かくしない。

細切れにするコストよりも、レビューする人間の認知不可が許すレベルであればある程度まとまった単位でレビューして実装速度を優先する派。

チーム開発ならもうちょっとちゃんとする。

テストは、ある程度実装が進んでリファクタリングが辛くなってきたタイミングで作ることが多い。

カバレッジやミューテーションテストなど、定量的にテストを評価できる仕組みは導入する。

バックエンド側のテスト実装は正直かなり楽で、行数や認知的複雑度を厳しく制限して単一責務の原則を守って実装しておけば、AI がかなり高精度なテストを出してくれる。

これもテストファイル実装プランを作ってもらって「ここからここまでのテスト 20 ファイルを実装してね」をレビュー挟んで繰り返す感じ、例えばミューテーションテストのkill率100%ならそんなに詳しくは見ない。

フロントエンドはテストの定量指標での評価が難しいので、そこはその分レビューを頑張るしかない。

自分はこんな感じでやっている。

感覚としては、優秀だけどシステムのアーキテクチャ全体の責務を負ったことはない経験不足の2年目やSESの部下を扱うEMに近いのかなぁ。

周りの話を聞いていると、もっともっと AI に自律的にいろいろやらせているようにも聞こえる。

これでも 1日1人で数万行レベルはコードを書けてるので、AIない時代に比べると数ヶ月分の成果を1日とかで出してることになるが、もっと本気出せるのかなぁ。

それでも人間が干渉しすぎなんだろうか。

「全機能分プラン作ってね！そこから良い感じの粒度でコミットも自分でやってね！」みたいな指示を良い感じに出せたとしても、指示がでかすぎると、脆弱性盛々になったり、lint エラーループでパニクって linter オフにし始めたり、テスト通すためにエラー握りつぶして assertTrue(true) し始めたりする。

それは流石に許容できないレベルじゃない？が紛れ込むリスクが上がりすぎるんじゃないかなぁ。と思ってるんだがどうだろうか。。。

あとツールはあんま入れてないねkiroとかspec-kitとか、ガチガチ細切れで仕様書作るメリットもあんま感じなかった。

mcpもserenaくらいしかいれてないや、トークン節約してレートリミットの猶予伸ばした方が結局開発早くなるかなって。

いろいろ入れた方がいいんだろうか。

完全にオレオレでこんな感じでやっているんだけど、みんなspec 駆動開発というものをどんな感じで、具体的にどうやっているのかが知りたい。

Permalink | 記事への反応(0) | 13:05

■中道 改革 連合(チュドカク)の真価はパヨクの敗北を確定させたこと

チュドカクについて、はてなあたりでは「どうせ勝てない」「野合」「カルト批判がブーメランになる」といった批判が並ぶが、正直に言って重要なのはそこじゃない。お前らは分かってない。

勝てるかどうかでも、理念がどうかでもない。最大の価値は、立憲民主党というパヨクの選択肢を完全に解体し、逃げ道ごと潰したことにある。

立憲は長らく一応はリベラル左派という顔をしてきた。反原発、立憲主義、そういった綺麗事でパヨクに「正義は我々にあり」みたいな幻想を抱かせてきた。

だがチュドカクは、その幻想を根こそぎ破壊した。

原発再設置OK、安保法制は合憲、憲法改正もOK。これは、立憲が掲げてきた建前とほぼ真逆だ。にもかかわらず、その路線でチュドカク合流することに対して、党内で大きく異論を唱えている“有名どころ”はほぼ存在しない。名前が挙がるのは、もはや鼻つまみ者扱いの原口くらいなものだ。

枝野、岡田、蓮舫といったリベサヨのお歴々たちはどうか。参院議員で立憲に残る蓮舫は置いておくとしても、枝野に至っては、昨年の時点からこの合流を事実上追認・迎合する発言をしてきた。つまり何が起きているかというと、リベサヨ政策ではもう選挙に勝てないと、立憲結党の当事者自身が認めてしまったということだ。

もし単なる連立や選挙協力であれば、「主張は捨てていない」「現実的に組んでいるだけ」という言い訳が成り立った。パヨクはいつものように、敗北を戦術的妥協として物語化できたはずだ。

しかし今回は違う。衆議院議員を離党させた上での新党結成である。

これは、「我々はその主張では戦わない」「その路線は終わった」という自己否定に等しい。連立でも共闘でもない以上、「まだ立憲的リベラルは生きている」という逃げ道は存在しない。

だから、チュドカクが左翼だの何だのと叫んでいる連中は、本質が見えていない。

この新党の価値は、自民に勝てるかどうかじゃなく、パヨクに媚びることが“選挙に勝てる選択肢”として存在する余地を完全に消したことにある。

共産やら社民なんて立憲やチュドカク以上に人気がなく先がないから語るには及ばない。

結局、高市の突然の解散宣言とチュドカクの成立によって日本のパヨクは決定的に敗北したわけだ。これだけが重要なことで、チュドカクが議席を減らそうが増やそうが関係ない。

パヨクが敗北したという厳然たる事実は変わらないのだから。

結論としては、パヨクは存在価値ないから消えてどうぞってこと

Permalink | 記事への反応(5) | 12:45

2026-01-18

■togetterのコメント欄…

「私の個人的体感ですが、「性暴力サバイバーだから」を理由に過度に庇護された経験は乏しく、「サバイバーだからって何をしても許されると思うな」と厳しい目線を向けられ、個々の感情にまで踏み込まれ、言動をジャッジされることのほうがはるかに多かったです。」

https://posfie.com/@kekkonshimasita/p/UuYk47p#c15731158&thread

八百旗椿妃@ba_fei83371
日本語でok

苦労🌆@44990
何でも良いけど、創作物を叩く理由にするのはやめてくれ。

名前はまだない@774rider
サイババー

まー@oFLX44gs8y8198
ちっとイラっとしたからコメントする。この人は”言ってない”けど思ってるんじゃないのか？あんなにつらい目にあった自分に優しくしない社会は間違ってると思っている様に見える。態度の端々にそういうのが見えるから言われるんじゃないのか？人には人それぞれの地獄があるとかってのはどこで聞いたんだったか。信頼できる相手以外には自分の地獄を開示しない方が良いと思うよ。

furudera@furudera1
なぜ性暴力サバイバーであることを伝えたいのかがいちばんの問題。伝えることによって何を求めているのかまで、しっかり伝えないと相手は労りが欲しいのか何なのかが分からない。伝えることによってどうなりたかったのか？、苦しみから逃れたかったの？、何が苦しかったのか？、どうしてほしいのか？、そこら辺を相手任せにしたらそりゃ色々な反応になるでしょ。