Shunei / しゅんえい @mFLOCSS

API キーや秘密鍵、うっかり AI に投げたことありませんか🤔 自分が気をつけていること: ・認証情報は .env に分離し、AI に渡すデータにハードコードしない ・万が一送ったら、該当のキー・パスワードを即差し替え AI サービスのログにどこまで残るか分からない以上、「渡さない」が最もシンプルな防御かなと思います。 ライン、決めていますか？

Claude Code のエージェントにモデルを使い分けるようにした。コーダーは Sonnet、プラン策定は Opus、情報収集は Haiku。 先週、週間制限を100%使い切ったので見直したら、Opus でコード書かせてたのが無駄遣いだったかも🤔 みなさんはモデルの使い分け、どうしていますか？

Did you know you can now connect your GA data directly to LLMs like Gemini? ✨📊 By setting up the new Model Context Protocol (MCP) server, you move from manual reporting to strategic, AI-powered analysis. ▶️ Hit play to see the complete setup process → goo.gle/47CsGrA

Introducing EmDash — the spiritual successor to WordPress. Serverless. TypeScript. Securely sandboxed plugins via Dynamic Workers. cfl.re/3NPVfev

Claude Max 20x の週間制限、100%使い切った。 CSS設計の書籍レビュー・リファレンス実装・仕様書の対立的レビュー、そして Claude 自体のチューニング（フィードバックループで精度を上げていく作業）を回した結果。 バグで消費が膨らんでいる報告もあるので、純粋な使用量かは分からない。ただ、兼業フリーランス1人でここまで回せる一方、Opus と Sonnet の使い分けというコスト設計が次の課題🤔

#デイトラ 6周年、おめでとうございます。 自分の変化を振り返って書きました。 狭い世界に20年いたエンジニアが、デイトラで世界を開いた話｜Shunei / しゅんえい @shunei_web note.com/shunei_web/n/n…

「仕様を定義し、仕組みを作り、自律させる」 最近の自分の振り返りで、それが自分の本領だと気づいた。 初芝さんのセミナー「AI時代のマーケティング基礎講座」で、AIで分業コストが下がり全体を設計して回す「大ディレクター」が強くなる、という話を聞いて腑に落ちた。自分がやりたいことと、時代の方向が合っている。 自分の仕事を決めつけない。その言葉が一番刺さった💡

技術書の全章プランを詰めていて「この章、誰に向けて書いてるんだっけ」と何度も立ち返った一週間。 書き進めるほど「全部入れたい」衝動が出てくるけど、読者が1人に絞れていれば取捨選択は迷わない。判断基準があると、捨てる決断が速くなる🤔 みなさんは何かを作っていて「詰め込みすぎたな」と気づいた瞬間、ありますか？

Web制作実践部のClaude Code勉強会に参加。ともひろさん(@TomoCS_TomoCS)がAIで10分足らずで精度の高いページを組み上げていくデモ、見ていて引き込まれた😊 でも、AIの出力を見て的確に判断して導けるかは自分の実力が問われるなと。学習中はAIを相談役にしつつ自らコードを書いて、判断力を積み上げていくのが大事🤔

@leoleo0729 @daylytrial_comm れおれおさん、こちらこそありがとうございました！ AIが知らないCSSプロパティを教えてくれるの、わかります。逆にAIが間違えてることに気づいて直すこともあって、お互いに伸びていける感じがあります💡

@shunei_web @daylytrial_comm しゅんえいさん✨️ ご参加ありがとうございましたฅ^•ω•^ฅ それぞれ違う視点からAIにアプローチされていてすごく面白かったですね(*•̀ㅂ•́)و✧ Web制作の場面でもAIにきいたら知らなかったCSSのプロパティを出してきてくれることもあり勉強になることも💡

参加してきました！皆さん AI で作品を作って、公開・利用まで持っていっていてすごかった✨ 改めて思ったのは、AI の本領はコードの先にあるということ。自分は Claude Code に知見の整理や判断ログの記録まで任せていて、コーディングより「考えた結果を仕組みに残す」ことに価値を感じています。 ただ、カリキュラム受講中は自力でこなした方が力になる。判断基準が身についていないうちに AI に頼ると、なぜそう書くかがわからないまま進んでしまう。AI は相談役くらいがちょうどいい気がします✨ みなさんは AI をどんな場面で使っていますか？

交流会でコーダーさんと CSS 設計の話になった。BEM は使っているけど FLOCSS は未経験とのこと。 「このクラス、どのファイルに書けばいいか迷う」という話が出て、mFLOCSS の8層を説明したら「判断基準があると迷わなくなりそう」と言ってもらえた。 設計って、書き方よりも「なぜそこに置くか」の判断基準が本質なんですよね🤔 CSS の置き場所、何を基準に決めていますか？

mFLOCSS v1.2 のアップデート中、仕様書を直したら実装も直す、実装を直したら技術書も直す、の連鎖がずっと続いている。 面倒だけど、これをサボると後の自分がズレた前提で進めて余計に時間を使うことになるので、結局やるしかないかなと🤔 みなさんの個人開発で、ドキュメントと実装がズレてて困った経験ってありますか？

CSS設計のルールを仕様書に言語化したら、自分の実装の矛盾が次々見つかりました。 たとえばルールの強制度。27件の MUST のうち、11件は実は SHOULD だった。自分だけで使うなら全部 MUST でも困らない。でも他の人にも使ってもらうなら、実務に合わせる余地が必要だった🤔 「自分にとっての正解」と「他者が使える設計」は違う。その差は、言語化しないと見えなかったんですよね。 自分のやり方を言語化しようとして、気づいたことはありますか？

仕様書に「思考フレームワークであり、ルールブックではない」と書いた直後、AI レビューで「MUST が20個以上あるのにフレームワークって矛盾してませんか？」と返された😅 確かに。読み返すと、言いたいことと書いてあることがズレていた。 1人で仕様を書いていると、自分の頭の中では整合しているように見える。でも第三者の視点を入れると、書いた本人が気づけない矛盾が出てくる。 「自分が書いたもの」を疑うのって難しいですよね💡

技術書の執筆を AI に任せていて、最初は自分が全部レビューしていた。毎回同じような指摘をしている自分に気づいて、レビューの仕組みを作ることにした。 ポイントは、執筆とレビューを別セッションにして経緯を一切渡さないこと。すると忖度なく、初見の読者と同じ目で指摘してくれる。 チューニングを重ねるうちに指摘が減っていって、自分は重要な点だけ重点レビューすればよくなった。レビュー負荷、結構減ってきたかも🤔

@yuuweb00243 ゆうさん こちらこそありがとうございました！ mFLOCSSの話を聞いてもらえて嬉しかったです。 近々バージョンアップ版をリリースしますので、使ってみてもらえたら嬉しいです✨ 次回は「D」で撮りましょう📸

@shunei_web しゅんえいさんは昨日はありがとうございました✨ AIのお話やmFLOCCSのお話など、 とても参考になりました😊 次回はちゃんと「D」で写真撮りましょう！

松本の作業交流会に初参加してきました。とみさん( @__to__my )主催、第5回！ 皆さんそれぞれ AI を活用されていて、自分とは違う使い方や視点が聞けて参考になった。直接話すと、テキストだけでは見えない工夫が出てくるのが面白い。 こういった交流会にどんどん参加していきたい🍵 @pon_tsuyo_31 @yuuweb00243 @moto_fastest

@pon_tsuyo_31 @__to__my つよぽんさん こちらこそありがとうございました！ GitHub導入とポートフォリオ、まさに基盤作りですね。 AIは基盤ができてからの方が活きるので、いい順番だなと思います。 応援しています💡

@shunei_web @__to__my しゅんえいさん、昨日は作業会ありがとうございました😊 AIの活用方法のお話とても勉強になりました！ 私はまずはGitHubの導入とポートフォリオ作成を頑張りつつ、少しずつAIも触っていこうと思います😌

@__to__my @pon_tsuyo_31 とみさん こちらこそありがとうございました！ 初参加でしたが居心地がよかったです。 AIの使い方、本当に人それぞれで面白いですよね。 次回もぜひ参加させてください😊

@shunei_web @pon_tsuyo_31 しゅんえいさん！ 参加いただきありがとうございました😌 皆さん、各々AIの使い方が違っていて参考になりますよね💡 すごくbですね😂