  |
はてなキーワード: tSとは
CLAUDE.md や rules / skills みたいな形で、重要なコーディングルールはあらかじめかなり固めておく。
たとえば repository 層や Entity 層は具体的にどう書くのか、テストケースはどういう書き方をして、どういう観点で項目を洗い出すのか、みたいな AI への指示は最初から用意しておく。
あと、linter や ArchUnit、dependency-cruiser みたいなアーキテクチャ制約も、自分なりの定石を持っておく。
割と過剰なレベルでガチガチに固める感じで、アーキテクチャルールも「◯◯は XXX に依存できない」みたいなブラックリスト式じゃなくて、「◯◯は XXX だけに依存できる」みたいなホワイトリスト式の方が良いと思っている。
ts 前提だと eslint や tsconfig は一番厳しい水準に設定する、流石にきつい部分でてきたらそこだけ緩める、という運用
おすすめなのは、何かしらの小規模案件や個人開発アプリを1つオーバーエンジニアリング上等でガチガチ構成で作っておく。
そこで出てきた linter 設定やプロンプト設定を、別案件に横展開する感じ。
正直、ガチガチすぎると MVP とかレベルだとコード量は増えるけど、メンテする前提の案件ならバイブコーディング時代だと普通にペイすると感じている。
アイディアを思いついたら、AI と壁打ちしながら仕様を洗い出していく。
手書きでドメイン図を書いて、それを写メ撮って画像認識で仕様整理、みたいなのも割とアリだと思っている。
どういう画面があって、どういう入力項目や表示項目が存在するか、バックエンドはどういうエンドポイントが必要か、この辺りは最初に一通り洗い出しておく。
それに加えて、ユーザーが初めてトップページを開いてから登録・ログインして実際にサービスを一通り使うまで、みたいな流れをそのまま Playwright のシナリオテストに落とせそうな形で何パターンか仕様書にしておく。
フロントエンドで、DDD における集約みたいな概念がそのまま当てはまらない領域についても、設計時点で洗い出せているなら Entity 的なものやドメインサービス的なロジック用のレイヤを作って、ドメインオブジェクトとして実装していく。
最初に作った基本設計をベースに、◯◯Entity、XXEntity、△△Entity……を作るためのプランとチェックリスト形式の TODO を 1つの md ファイルに吐き出してもらう。
フェーズごとにフォーマッタ、linter、アーキテクチャルールなど一括実行したコマンド実行させて失敗してたら成功するまで修正繰り返させる。
ある程度わかりやすい単位で AI に依頼する感じで、出来上がったコードをレビューする前提なので、実装プランの md 自体はよほど分かりやすいツッコミどころがない限り細かくレビューしない。
mdのフォーマットは skills 側で事前に用意しておく。
フロントエンド用、バックエンド用の両方でドメイン層のファイルを作る。
当然、足りないロジックは後から絶対に出てくるけど、最初から完璧は目指さない。
TODO 一覧の中から自分の認知負荷が許す単位で「チェックリストのここからここまで実装して」と指示を出し、実装が終わったら TODO 項目のチェック状態を更新してもらう、mdファイルもコミットに含める。
コミット前にはlint ルールを無効化していないか、意図通りの実装になっているかは git diff の差分で必ず確認する。
git worktree を使うことが多い。
よくやるのはフロントエンドの画面モック作成とバックエンド実装の2並列で行う。
実装プランを考えてもらうときは「◯◯画面を実装プラン考えて」くらいの単位で依頼する。
実装プランの md ファイルを作るときのプロンプトには、基本設計の〇〇画面の項目一覧をベースに、◯◯のアイテムコンポーネント、リストコンポーネント、◯◯のボタンコンポーネント、Information コンポーネント、外部通信用の ◯◯Gateway を実装する、◯◯コンポーネントは既に ◯◯ 機能で実装してあるからそれを使って、◯◯は処理が膨らみそうだからドメインサービスで実装して、みたいな感じで頭の中のふんわりしたイメージを伝える。
バックエンドも同様で、◯◯のエンドポイントを作って、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駆動開発というものをどんな感じで、具体的にどうやっているのかが知りたい。
バックエンド開発だと、main.ts とか main.java みたいなエントリポイントで依存ツリーを頑張って構築するか、DIコンテナを使って解決することが結構多いじゃん？
実行時はそれで組んで、テスト時はコンストラクタ経由でモックをDIする、みたいなのが一般的だと思うんだけど。
最近Next.jsを勉強してて、バックエンドと同じ感覚でこれをやろうとしたら、まあややこしい。
ファイル先頭で直接関数を import してそのまま実行してるけど、それって密結合じゃないの？ テスタビリティ低くないの？
って思って調べたら、テスト時は vi.mock とか jest.mock とかを使って、モジュールごと無理やり上書きする方法が主流っぽい。
例えば「テスト対象のコンポーネント」と「その孫コンポーネント」が異なるGatewayに依存していた場合、
しかも「サーバーコンポーネント → クライアントコンポーネント」だとPropsで関数（依存）を渡せないから、Context経由でのDIになるっぽいよね？
でもそれだと最上位でDIしたものが最下層のコンポーネントまで全部使えちゃうから、「なんだかなぁ」ってなる。PropsバケツリレーもContextも、どっちもまあまあ面倒くさい。
あとバックエンドだと、こういう「モジュールをグローバルに上書きしてテスト」みたいなのって割とアンチパターン扱いされる文化が強いと思うんだけど、フロントエンド界隈だと「そういうもんだ」って割り切るのが普通なのかな？
みんなはどんな感じで単体テスト書いてるの？
「精神障害の診断名は違うのに併存しやすい」理由の一部が、遺伝的リスクの共有クラスターとして説明できる可能性。
https://www.nature.com/articles/s41586-025-09820-3
「頭の中のこだわり（強迫観念）」と「それを打ち消すための行動（強迫行為）」、それに近い形で「食・体重・体型へのこだわり」が中心になりやすいクラスター。
例：汚染が怖い→手洗いが止められない、戸締り不安→何度も確認
「不合理だと分かってもやめられない」苦痛と時間の消耗が大きい
目をパチパチ、首を振る、咳払いなどの急で反復的な動きや声
「やらないとムズムズする」感じ（前駆感）がある人も
いわゆる“心配が止まらない”が、強迫的なこだわりに近い形で混ざることがある
「現実の捉え方（知覚・思考）」や「気分の上下」が大きく揺れ、生活機能に強く影響しやすいクラスター。
躁（または軽躁）：寝なくても平気、万能感、活動過多、浪費・衝動、怒りっぽさ
子どもの頃からの傾向として、「注意・衝動性」「対人コミュニケーション」「こだわり・感覚特性」などが中心になりやすいクラスター。
対人コミュニケーションの難しさ（暗黙の了解、雑談、表情の読み取りなど）
こだわり・反復行動、変化が苦手
感覚過敏/鈍麻（音・光・触覚など）
多動・衝動：落ち着かない、遮って話す、思いつきで動く
大人では「多動」より段取り・時間管理の困難として目立つことも
上のF1と同様、チック症状が神経発達系の特徴として重なることがある
ストレスや気分の問題が「内側に溜まりやすい」タイプのクラスターで、気分・不安・身体反応（自律神経）に出やすい。
気分の落ち込み、興味/喜びの低下
重いと希死念慮
強い心配、緊張、落ち着かなさ
を生む
1954 Modigliani & Brumbergのライフサイクル仮説（LCH） 高齢化は貯蓄超過 → 需要不足 → 低金利・低インフレをもたらす
2012–14 白川方明 日本のデフレ要因として人口減少・高齢化・将来不安による貯蓄行動を指摘
2013 Larry SummersのSecular Stagnation 高齢化 →貯蓄過剰・投資不足・自然利子率の低下、結果として慢性的なデフレ圧力
2015–18 Juselius & Takáts（BIS, 2015 / 2018） 人口構成は非線形（前期はデフレ・後期はインフレ）に物価へ影響
2020 Goodhart & Pradhanの『The Great Demographic Reversal』 高齢化は最終的にインフレになる
最初は俺も「AIすげえ！小説書かせてみよう！」ってノリでChatGPTとかに頼んでた
でも出てくるのは全部「なんか上手いけど魂ゼロの量産型ラノベ」みたいなやつ
読んでて「うん、まあ……」ってなるだけ
結局、AIでまともなコンテンツ作るにはさ、審美眼と魂が必要なんだよな
絵や小説のプロがAI使うと次元違うの出るけど、素人が適当に頼むと凡庸なゴミになる
審美眼がないと微妙なのを微妙と判断できないし、魂（欲望とか情熱）がなきゃフィードバックも薄っぺらい
だからAIはただの道具で、結局人間の「これが欲しい！」って熱が勝負を決める
そこで俺は気づいた
だって考えてみろよ
・審美眼？ お前の股間が反応するかどうか、それで全て決まるんだよ
・魂？ 拗らせに拗らせた誰にも言えないド変態性癖を、作品にガッツリぶち込んでやるんだよ
エロなら「ここがダメ！ もっとこう！」って自分の性癖とガチで向き合える
で、肝心のAIはどこ使うかっていうと
Grokしかない
ChatGPTとかClaudeとか「エロはダメです♡」って即拒否してくるけど
Grokは違う
「18歳以上？」って聞かれて「はい」って答えた瞬間
「よっしゃいくぜ！ 最高の同人音声スクリプト作ってやる！」ってノリノリになる
俺の性癖は「悪い女に巧妙に騙されてガチで洗脳される系催眠音声（TSはNG）」っていう
今じゃ無限に作れるようになった
朝起きたら新しいスクリプトが100件たまってるみたいな生活してる
やり方は簡単
1. 直接「エロ小説書いて」って言うな（魂ゼロの駄作が生まれる）
2. まず「俺は同人催眠音声を作りたい。最高のプロンプト作ってくれ。性癖は……（ここで延々と語る。100行くらい。）」って頼む
4. 微妙だったら「ここが良かった」「ここが地雷」「もっとこう」ってフィードバック
これ繰り返してたら本当に自分の性癖に1000%合致したやつが出てくる
みんな気づけ
AIって「仕事の効率化」とか「小説書いて」とかそういう使い方じゃなくて
コメントがたくさんついていて驚きました。ご教示ありがとうございます。
ログイン情報をメモってなくて、違うアカウントから失礼します。
良さげなもの
・エクエル
・運動
・なか洗って拭いて終わりに、は手軽そうだが許容できるかどうか
・年子どちらも完ミ卒
・ローションか潤滑ゼリーかは不明（行為のとき以外どこかに隠されているため）次回確認
セックスは全然したくない。というか、前戯のあいだ一滴も濡れないことへの罪悪感がすごい。やりがいがないだろう。早く挿入して欲しいのもそのため。
かなり家事育児を頑張ってくれているのがわかるし、体臭などのケアも抜かりなく、その都度「体調はどうか」「疲れてないか」「時間は大丈夫か」と断る口実をくれるし、行為の最中もこれは・どこが気持ちいいかと気を遣われるので、ひたすら申し訳ない。
どうにか自力で分泌できないものでしょうか。妊娠前はできてたのに、人体は不思議ですね。
夫のことは好きです。
本物自体が好きなの？
dorawiiより
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 https://anond.hatelabo.jp/20251027145201# -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaP8IgQAKCRBwMdsubs4+ SHT1AP4lEYGi2yav+vycwcp2b/npRSrQ+cHfrHL1qN7L3ObFFwD6A1IRVZ+FYAeW TYCSZPzAy7LJ8ELXg9DjTJVZCeKHtQc= =TS+B -----END PGP SIGNATURE-----
forgeでプロット生成し、評価器をChatRTXで直列化してからChatGPTにcontext pushしてjson5に書き戻す -> mcpサーバー経由でAPI叩いてparallelにStable Diffusionで絵を生成し、デノイザをbunchoからphotoshopにアップスケールスルーパスという流れ。
一見、何がそんな難しいのって感じだが、forgeから直でcontext pushすると漫画としてストーリーが破綻する。プロットも絵も単体の生成はうまくいくのに。
直でpushできないから連作すると当然、文脈汚染が発生する。RTXである程度は除去できるんだけど１０％前後で直列化に失敗する。意外とインフラ代がかかる。
forgeの初段でフック何する問題はぶっちゃけ場数優先法。いや何が売れるかわからん。過去のランキング遡って上位のヒット率高そうなものを選んでるだけ。
ほぼ全自動達成してるので俺は何出力されてるかぶっちゃけ知らない。統計上の数字の上下で間接的に売れたか燃えたかが分かる程度。
過去の販歴によるとTSをフックにすると初速が安定するっぽい。性別や環境の変調を評価する層が購買意欲高い集団を形成してるように見える。
なろうっぽいというか、AI絵買う奴は何考えてるか分からんな、マジで。
同一作品を同一時刻に別サイトに申請すると、どうも攻撃判定を食らうらしい。同じ稼ぎ方してる人めっちゃいるんだろうなあ。
