がみちゃん｜地方企業のDX・AI化の専門家

本日からLP解禁しました！ neuroflow.jp サービスについて、簡単に説明させていただくと、地方企業のDX、AI化のお手伝いをさせていただきます！ 私は正社員として、地方の企業でDXを推進する中で「Excel問題」をずっと見てきました。 kintone入れても現場が使わない。 SaaS入れても業務に合わない。 なら、御社のExcelをそのまま専用システムにすればいい。 そう思って作ったのがNeuroFlowです。 お気軽にご相談ください! neuroflow.jp #AI　#中小企業DX　#製造業DX　#脱エクセル

AIに社内システムを育てさせるプロジェクトで、「新しいセッションでAIが迷子にならない設計」がワークしてるので共有します。 Claude Code はセッションを跨ぐと記憶がリセットされるので、毎回ゼロから状況把握してもらう必要がある。 ここで詳細ファイルを全部読ませるとコンテキストが膨らんで判断精度が落ちるし、情報が少なすぎると前回の決定を覆す提案が出てくる。 設計はシンプルです。 ルートに置くのは2ファイルだけ。 README.md と PROGRESS.md。 README.md には「プロジェクトのゴール」「読むべきファイルの順序」「絶対ルール」だけを書く。 戦略の核心を1分で把握できる粒度。 PROGRESS.md には「現在のフェーズ」「次にやるべきタスク（着手順）」「作業ログ」を書く。 新セッションでこの1ファイルを読めば、今日何をやるべきかが即分かる。 詳細ファイル（技術仕様・ナレッジ・出力フォーマット）は knowledge/ フォルダに全部入れて、タスクに着手する時だけ読ませる。 この構造の良さは、AIに与えるコンテキストをタスクの深さに応じて段階的に増やせること。 軽いタスクなら2ファイルだけで判断できるし、記事を書く時だけ knowledge/ 配下を追加で読む。 副産物として、このプロジェクトは Claude Code じゃなくても動きます。 他ツールでも、まず README.md 読んで、そこから PROGRESS.md に誘導される。 AI固有の情報（MCPの使い方など）は CLAUDE.md という別ファイルに閉じ込めてあるので、他ツールに渡しても混乱しない。 AI駆動開発で意外と効くのは、コンテキストを入れる順序の設計です。

GPT-image2.0本当凄まじいですよね。 昨日から販促チラシやスライド、SEOコンテンツを量産しまくっています！

GPT-image2本当すごいｗ

Claude Codeの「工数」、ここをちゃんと理解してる人は意外と少ない気がするので整理します。 結論から言うと、工数は「何％性能アップするか」の設定ではないです。 Anthropic公式の説明に近い言い方をすると、これは Claudeがどれだけ積極的にトークンを使って取り組むかの設定です。 なので、工数を上げると変わるのは単なる「賢さ」だけではなくて、たとえば次のような部分です。 ・どれだけ深く考えるか ・どれだけ丁寧に説明するか ・どれだけツールを使うか ・どれだけ時間をかけるか ・どれだけコストがかかるか つまり、工数は思考の粘り強さ・調査の厚さ・説明の厚さをまとめて調整するノブ、と理解するとかなり近いです。 ここで大事なのは、 「中（medium）→高（high）で毎回同じだけ良くなる」わけではないこと。 これは公式も、effort を 「厳密なトークン上限ではなく、振る舞いの強さを示すシグナル」 として説明しています。 要するに、 ・毎回きっちり同じ差が出るわけではない ・ただし、上げるほど深く・重く・丁寧になりやすい ということです。 各段階をざっくり整理するとこうです。 ◆低（low） かなり効率重視。 速さ・コスト優先で、単純作業や大量処理向き。 必要以上に掘らず、ツール呼び出しも控えめになりやすい。 ◆中（medium） バランス型。 低（low）ほど切り詰めないが、高（high）ほど粘らない。 日常的な依頼をそこそこ良い品質で返してほしいときの現実解。 ◆高（high） 品質重視側。 これがデフォルト相当です。 つまり、工数を明示的に変えていないときの基準は、基本的にここ。 複雑な推論、難しめのコーディング、重要な作業ではこの水準が基準になる。 ◆超高（xhigh） Opus 4.7で追加された段階。 特にコーディングやエージェント的な作業で、高（high）よりさらに踏み込んで調査・試行・ツール利用を増やしたいとき向け。 ここは公式も、高（high）より意味のあるトークン増加が見込まれると案内している。 ◆Max 絶対最大能力寄り。 ただし万能の常用設定ではなく、仕事によっては「考えすぎ」になることもある。 公式も、コスト増の割に改善が小さい場合があると書いている。 なので実務感でいうと、 ・雑務、整形、軽い要約 → 低（low）〜中（medium） ・普段の調査、文章作成、通常のコード作業 → 中（medium）〜高（high） ・難しいバグ調査、複数段階の設計、探索的な実装 → 高（high）〜超高（xhigh） ・本当に重い難問 → Max という使い分けがかなり自然です。 一番誤解しやすい点を一言で言うと、 工数は「固定の性能倍率」ではなく、Claudeをどれだけ粘り強く働かせるかの設定です。 ここをそう理解すると、 「中（medium）と高（high）で何が違うの？」 「高（high）がデフォルトってどういうこと？」 「Maxにすれば常に最強？」 みたいな疑問がかなり整理しやすくなります。

これが地方製造業DXのリアル。 「謎の集約行」と「その場限りの手入力」が混在するカオスなExcelをシステム化しようとして、ロジック整理に詰んでた。 それをClaude Codeが一瞬で解読。 「基本列は1行1レコードですが、AR列は商品全体での集約です」と、完璧な仕様解説と対応策を出してきた。 このAI、現場の闇を晴らす光すぎる #業務改善 #Excel #AI活用 #Claudecode

Claude Codeのソースコード流出で見えた設計思想、使ってる側としてメモ。 ・CLAUDE.mdは毎ターン再注入される →だからプロジェクト固有の指示がブレない。僕が在庫管理や生産計画のシステム作る時、ここに業務ルール書いておくと一貫して守ってくれてたのはこの仕組み ・コンテキスト圧縮は5段階 →長い会話でも精度が落ちにくかった理由がこれ ・"Conway"という常時稼働エージェントが存在 →バックグラウンドで何か動いてる感覚はあった 4/7にAnthropicの"What We Shipped"ウェビナーがあるらしい。この流出についてどこまで触れるか気になる。 非エンジニアでClaude Code使ってる身としては、中身を知ったことで逆に信頼度が上がった。設計がちゃんとしてる。

Claude Codeのソースコードが流出した件。 npmのv2.1.88に59.8MBのソースマップが混入→TypeScript約51万行が丸見えに。 個人的に一番驚いたのは「CLAUDE.mdが毎ターン再注入されてる」って設計。僕はCLAUDE.mdにプロジェクトの設計思想を全部書いてるんだけど、だからブレなかったのか、と腑に落ちた。 コンテキスト圧縮が5段階あるとか、"Conway"って常時稼働エージェントの存在とか、中身はかなり練られてる。 流出自体はまずいけど、使う側としては「だから安定してたのか」って納得感のほうが大きい。

@0x__tom CLAUDE.mdが毎ターン再注入される設計、実際に使い込んでると体感で「これ毎回読んでるな」って気づくんですよね。僕は業務システム24個作る中でCLAUDE.mdをかなり育ててきたけど、短く保つのが正解というのは完全に同意。詳細はskillsに逃がして本体はルールだけにするのが一番安定します

海外でClaude Codeの流出コードの分析が進んでて、めちゃくちゃ実用的な発見が出てきてる。「CLAUDE.mdは会話の毎ターンに再注入される」。これ、使い方が根本的に変わる話。 ↓↓↓流出コードからわかったこと↓↓↓ ・CLAUDE.mdは1回読まれるだけじゃなく、毎ターンシステムプロンプトとして再注入 ・つまりCLAUDE.mdの内容はどんなに長い会話でも「忘れられない」 ・逆に言えば、CLAUDE.mdの文字数 × 会話のターン数 = 消費トークン。冗長な内容はコスト増（ただしプロンプトキャッシュで実コストは軽減される） ・5種類のコンテキスト圧縮戦略も判明（Microcompact→Context Collapse→Session Memory→Full Compact→PTL Truncation） ・コンパクション後も直近のファイルやTODOを再注入して作業コンテキストを維持する設計 ・「Claudeが忘れた」は実際にはメッセージ削除ではなく、圧縮プロセスで情報が落ちた結果 ・CLAUDE.mdはこの圧縮の影響を受けない特権的な位置にある この発見のポイントは、CLAUDE.mdが「プロンプト」ではなく「永続的なルールブック」として機能してるってこと。だからこそ短く保って、詳細は.claude/skills/やdocs/に分離するのが正解。 僕がずっと推してる.claude/フォルダの構造設計、これで裏付けが取れた形になる。CLAUDE.md本体にはWHY/WHAT/HOWだけ書いて、スキル、フック、ローカルCLAUDE.mdで段階的にコンテキストを注入する設計が最も効率的。 Claude Code使ってる人、自分のCLAUDE.md何文字あるか確認してみて。長すぎたら今すぐ整理した方がいい。

@toukatsujin 個別最適に走る気持ち、現場にいるとわかるんですよね。「とりあえずAI入れました」で満足して、データの流れは紙とExcelのままという現場を何度も見てきました。全体最適って結局「情報がどう流れるか」の設計なので、ツール導入より先にやることがあるはずなんですよね

大手製造業のDX（デジタル変革）の取り組みを聞いているとホント目まいがする。「我が社の強み」である工場の現場力が劣化しているからAIを使って何とかしよう。生産現場のカイゼンをさらに推し進めるためIoTを導入しよう。どれもこれも個別最適の話ばかり。全体最適の話など出てきやしないからね。

@reina_Notionxx Notion AIでOpus無制限はガチで強いですよね。Claude Code使ってる身からすると、同じモデルが別の入り口から使えるのに知られてないのもったいない。ツールって「何ができるか」より「自分の業務でどう使えるか」が伝わらないと広まらないので、現場目線の発信めちゃくちゃ大事だと思います

このポスト反応見る限り、まじでNotion AIのすごさ知られてないと思った… Notion界隈のみんな(?)もっとみんな発信してこ

@ai_depression これ刺さりました。AI使って整った文章書いても「で、あなたは何をやったの？」に答えられないと響かないんですよね。僕は泥臭く現場でシステム作ってきた経験をそのまま書くようにしてるけど、それが一番反応もらえる。結局「自分の手で触った事実」が最強のコンテンツなんだと思います

AIで発信の量も質も格段に上がったのに、フォロワーの反応が逆に薄くなってる現象に気づいてる？ 文章の質は明らかに上がった。毎日投稿もできてる。なのにいいねもリプも増えない。原因はAIが「文章力の格差」を埋めたから。つまりスキルの差が埋まって“上手い文章”の価値が暴落したんよね。 今までは文章力がある人だけが「刺さる文章」を書けたけど、AIによって中間層の差が埋まって、構成や表現パターンを真似できるようになった結果、タイムラインは小手先のハックポストまみれになった。 確かに冒頭が「え、待って」で始まるポストとか、「でも一番大事なポイントは→」で終わるポストは伸びたよ。でもそれは「タイムライン上で目立ってるから伸びた」に過ぎない。全員が擦り出した瞬間にトレンドは死ぬし、メタ頼りの三流発信者も全滅する。 これはライティングだけじゃなくて、コンテンツ販売でも情報発信でも同じ。中途半端なスキルしか持ってないと「これは伸びますよ」って情報に飛びつくことでしか稼げなくなる。 メタを回す能力がないから先細りになるんだよ。私含めだけど、AI時代でもライティングで飯を食えてる人間は押し引きでいくらでもメタを作れるから。 人の作ったメタを後追いするだけのイナゴになりたくないなら、 ・上位5％のスキルを身につける ・競合と差別化してメタの輪から外れる このどっちかしかない。 伸びてるテンプレで反応を取りに行くのは悪いことじゃないけど、そこから自分の価値を示せないと終わるよ。 1年以内に結果を出したいならスキルアップ以上に独自性を尖らせていくべき。AIで中間層のスキルの均等化が起きた以上、「この人にしかない切り口」「この人の経験からしか出てこない言葉」で戦うしかない。 自分が何を経験して、何を見てきて、何を判断してきたか。自身の解像度が高ければ高いほどタイムライン上で輝くし、AIでその強烈な個性を再現することもできる。 この解像度を上げるための棚卸しを5日間かけてやるのが今募集中のアイデアソン。メタの輪から外れて「自分にしかない武器」でマネタイズしたい人は固定ポストをチェック。

@Delete_All 本当にそう思います。「苦労してこそ仕事」みたいな空気が一番厄介で、効率化の提案が「楽しようとしてる」と受け取られる。僕が地方の中小企業でDX支援してて一番感じるのは、技術の問題じゃなくて「変わることへの恐怖」なんですよね。小さく成功体験を作って、空気ごと変えていくしかない

新しい技術の普及が進まない理由として会社や上司の理解不足が挙げられるけど違う。「仕事＝労力をかけてやるべきもの」という強い思い込みが原因だよ…。自分たちの仕事のやり方が否定されるのが嫌なんだよ。 / “中小企業でDX導入が進まないのは経営陣の「仕事に対する古…” htn.to/3tqarjZArq

@keiri_IS これめちゃくちゃわかります。結局Excelで頑張れば頑張るほど「あの人しかわからない」状態になるんですよね。僕も製造業の現場で似た状況見てきましたが、上流のデータ設計を先に整えないと、下流でどれだけ工夫しても限界が来る。経理だけの問題じゃなくて、会社全体の情報設計の話だと思います

経理業務、効率化の限界！？ 上流システムのデータが整理されていない。 販売など上流システムのマスタ不備で、欲しい情報が取れない。 仕方がないので、Excelテクニックを駆使してなんとか情報を処理する。 これが属人化の原因ともなる。 こればっかりは経理の努力だけでは対処できず。ここで効率化の限界がくる。 経理でやれることと言えば、効率化の原因を妨げている上流データの問題を情シスへ訴え続けしかないのか。

@fladdict 同感です。非エンジニアとしてClaude Codeで業務システム作ってる立場からすると、ソースコードの中身がどうなってるかより、目の前の業務課題を解決できるかどうかの方がずっと重要で。中身を知ったところで使い方が変わるわけじゃないですし、むしろ公式のアップデートに乗っかる方が合理的ですよね

Claude Codeのソースコードは動向気になるけど、普通に手を出さないほうが安全。触ったり見たりすることのリスクサイドのほうが大きいし、ことここに至ったらほっといても技術は普遍化されて普及するし、リスクみ競争も激しい、触らないほうが良いジャンルになった感ある

「最小構成が重要」、製造業側でも全く同じことを感じてます。僕も最初は「在庫管理を全部自動化」みたいに考えて破綻しました。結局「Excel転記をなくす」「棚卸の入力を減らす」みたいに1個ずつ切り出してClaude Codeで作っていったら、3ヶ月で24個のシステムになってました。小さい単位で作って回す方が、現場にも通りやすいんですよね

実務家としてClaudeで毎週バックオフィス系AIエージェント作り続けて分かったけど、月次ルーチン業務を100個以上の細かい業務モジュールに分解し1つずつ特化型エージェントを設計していかないとよくイメージされるような自動化には至らない。『クレカ未払金照合エージェント』のような最小構成が重要

めちゃくちゃわかります。「AIすごい」で止まって、実際の業務が何分減ったかまで見えてるケースって本当に少ないですよね。僕は製造業でAI使って在庫管理のExcel転記をWebシステムに移行したんですが、効果が見えたのは「棚卸が半日→2時間になった」って現場の人が言ってくれた時でした。課題が具体的じゃないと、AIの使い道も抽象的なままなんだなと

確かに「AIすげー！」はよく聞くけど、「AIで業務改善された効果スゲー！」はマジでぜんぜん聞いたことがない。 むしろAIで色々できるようになった"せいで"可処分時間減ってるまであるかもしれない。

逆にプログラマじゃない側からすると、ずっと「こうなったらいいのに」と思ってた業務の課題が、初めて自分で形にできるようになった瞬間でした。製造業でClaude Codeで在庫管理システム作った時、業務の困りごとをそのまま書いただけで動くものが出てきて。プログラマの方々が積み上げてきたものの上に乗ってるんだなと、使う側としても感じてます

バイブコーディングしてみて、AI凄いなぁ、こりゃプログラマという職業は確かになくなると騒がれるわなぁ、という思いと同時に、我々もよくこんなプロンプトに投げられる適当な説明から色んな複雑なシステムを構築運用してきたもんだよな。俺達頑張ってきたよなぁというある種の切なさがある

社内でClaude codeを導入することにして、現在定着支援を行っています。 Claudecodeってざっくり言うと、PCでできることは、ほぼなんでもできます。 それだけに、初めて使う人にしてみたら、どう使っていいか分からないとの事です。 ひとつ大事なことは AIは基本0→1を作るものではなくて、1を10、20、100にしていくツールと捉えることです。 使い手が知らないことを勝手に生み出すことは、ほとんどありません。 生み出せない訳ではなく、生み出す流れにならないです。 つまり、webアプリを作って本番で運用したいのであれば、それ相応の知識は必要です。 現在現場で導入している、研修資料ですが、ご興味ある方多ければ無料配布してみようかな〜

3日かけて作った業務システムへの上司の反応が「へぇ〜」だった時の虚無感、伝わる人いますか。 でもその後、現場の人が「これExcelに出せる？」って聞いてきた瞬間に全部報われた。 社内DXで一番キツいのは技術じゃない。「伝わらない」こと。 だから僕は「データベースに移行します」じゃなくて「Excelの入力が半分になります」って言うようにした。それだけで話が動き始めた。

非エンジニアの僕がAI駆動開発で3ヶ月で24個の業務システムを作った結果わかったこと。 技術力は関係なかった。 一番大事だったのは「この作業、なくせるんじゃないか」と気づける力。課題さえ言語化できれば、実装はAIがやってくれる。 逆に、課題が見えてない人はどんなにAIを使っても何も作れない。 プログラミングの時代が終わったんじゃなくて、「何を作るか決められる人」の時代が始まった。