gon｜テクノスタンダード 代表

株式会社テクノスタンダード代表
ニコニコ動画での大規模開発、PM・PdM経験を経て起業
取引実績：日産、味の素、ぐるなびなど
高度な技術力と挑戦を楽しむ仲間募集中！勉強会・LT会を定期開催！
フリーランス・正社員・インターン歓迎✨

[gon｜テクノスタンダード 代表 @gon_techno]

速くしたい・良くしたいとき、つい何かを足したくなりますが、効くのは減らすほうでした。使っていない処理、念のためのチェック、読まれないドキュメント。外すだけで軽くなり、壊れる所も減ります。足す前に「これは本当にいるか」を一度見る。引き算のほうが難しくて、効きます。 #設計 #エンジニア

[gon｜テクノスタンダード 代表 @gon_techno]

レビューが『孤独な校正』になる感覚、すごく分かります。うちは生成物をそのまま読むのをやめて、設計意図と受け入れ条件をこちらから先に書いてからAIに書かせる形にしました。読む対象が『意図とのズレ』に絞れると、量に押し流されずに済みます。

[厨二病エンジニア @rograma19]

LLMの進化でコードを書く量が減った代わりに、他人が書いた大量の生成物をレビューする時間だけが増えた。効率化の果てに行き着いたのは、ただの孤独な校正作業だった。

[gon｜テクノスタンダード 代表 @gon_techno]

わかります。急ぐときほど『誰の確認が要るか』を先に決めておくと、後戻りが減りますよね。うちは変更ごとに影響範囲と確認者をPRテンプレの欄に書くようにして、着実性を仕組みで担保する形にしたら、速さと安心が両立しやすくなりました。

[jota@プロのエンジニア @jyota9613]

リファクタリング

・なんでその改修をしたのか？
・その変更はどの人たちの確認が必要なのか？
・テストケースは落ちていないか？

急ぐことも大切だけど着実性の方が大切。

何を言うより何を言わないかが
ものすごく大切！

再度、確認がとても大切やなと感じた。

[gon｜テクノスタンダード 代表 @gon_techno]

障害対応の初動、平均40分から10分に縮まりました。効いたのは「最初に見る3つ（エラー率・直近のデプロイ・外部依存の状態）」を決めておいたこと。慌てて手当たり次第に見るのをやめて、順番を固定しただけです。初動が早いと、その後の判断も落ち着いてできるんですよね。 #障害対応 #運用 #開発効率化

[gon｜テクノスタンダード 代表 @gon_techno]

AIに実装を任せる量が増えて、レビューの仕方を変えました。人が全部読む前提をやめて、3つの層で見るようにしたら、レビュー時間が半分になっても品質は落ちませんでした。

この体制にしてから、リリース後の不具合が月12件から3件に減り、レビュー待ちの停滞もほぼ消えました。

3層レビューのポイント
■ 1層目：機械に任せる
型チェック・Lint・テストをCIで自動化
→ 人が見る前に機械的な誤りを落とす
効果：レビューが「設計の話」に集中できる

■ 2層目：AIに一次レビューさせる
観点を指定して危うい箇所を洗い出させる
→ 見落としの候補を先に潰す

■ 3層目：人は意図と設計だけ見る
なぜこの実装か、事業要件に合うか
→ 人にしか判断できない所に時間を使う

運用の注意点
・機械とAIの指摘を鵜呑みにしない → 最終判断は人
・観点は先にチームで言語化しておく
・小さく出す前提とセットで効く

AIに任せる量が増えているチームは、人の役割を「意図の確認」に寄せると回り出します。

#AI活用 #開発効率化 #マネジメント

[gon｜テクノスタンダード 代表 @gon_techno]

採用の面接でいちばん見ているのは、技術の量より「詰まった時にどう動いたか」です。分からない所を分からないと言えて、どこまで自分で調べ、どこで人に聞いたか。この動き方が仕事の再現性そのものなんですよね。完璧な回答より、詰まり方の説明に人柄と実力が出ます。 #採用 #エンジニアキャリア

[gon｜テクノスタンダード 代表 @gon_techno]

動かすまでと常時公開するまでは、別物ですよね。内輪はfunnelで十分でも、公開前提だと状態の持ち方や同時接続で設計が変わってきます。自分は『公開したら何が壊れるか』を先に一覧化してから、無料枠のうちに叩いておくと後の練り直しが軽くなりました。

[しゃかやみ @shakayami_]

Claude Codeでオンライン対戦ゲームを作った
tailscale funnelを使ってとりあえず動くことは確認した
サーバーを常時動かすならばCloudflare Workersあたりを使うことになりそう．内輪向けなら無料版でも余裕で足りるが，万が一公開するとなったら仕様を練り直す必要がありそう．

[gon｜テクノスタンダード 代表 @gon_techno]

作業前にメモを読ませて、区切りごとに記録を残す。地味ですが、セッションを跨いだときの手戻りが一番減る所ですよね。うちは記録の粒度を『次の自分が5秒で思い出せるか』で決めていて、細かく書きすぎないほうが引き継ぎは安定しました。

[Premiere効率化ラボ｜AI動画編集 @premiere_flow]

Claude Codeに、毎回の作業前にメモを確認させ、作業ごとに記録を残させるルールを作りました。

セッションが変わっても、前回までの経緯を引き継げるようにするためです。

地味ですが、これが一番効いている気がします。

[gon｜テクノスタンダード 代表 @gon_techno]

個人開発が続いた理由、振り返ると3つでした。①朝に30分だけ触る（夜は疲れて手が止まる）②動くものを先に出す（完璧を待たない）③自分が毎日使うものを作る。特に3つ目が効きました。人の要望より自分の面倒を起点にすると、作る理由が切れないんですよね。 #個人開発 #エンジニア

[gon｜テクノスタンダード 代表 @gon_techno]

並行数を増やすほど、設計のズレは目視で追えなくなりますよね。うちは依存の向きをCIで縛って、違反したらマージを止めています。注意力ではなく仕組みで止まる形にすると、速度を保ったまま密結合を防げると思います。

[ゆう｜フロントエンドに強いエンジニア @yuu_a_prog]

AIが書いたそのコード、良いコードと言えるか？

最近Claude Codeを4つくらい立ち上げて、並行で開発しまくってる。
量は捌けてるんだけど、後から見たら密結合な実装になってる箇所があった、、

密結合っていうのは、例えば関数Aと関数Bが強く依存してて、片方を直すともう片方も壊れる状態のこと。
Aを消したらBが動かない、みたいなやつ。

やばいのは、気づけなかったこと。
1つ1つの変更は普通に動くし、レビューも通る。
物量が増えると、コード全体としての設計のズレまで見る余裕がなくなる、、

なので、AIレビューに設計の観点を明示的に入れたり、並行数を減らして、自分が読み切れる量に戻すのもいいと思う。

人間の注意力に頼る設計は、AIの速度に負ける。

仕組み側で怒ってもらう状態を作りたいね

[gon｜テクノスタンダード 代表 @gon_techno]

フロントとAPIで別々にバリデーションを書いていて、ズレて事故る、を何度もやりました。スキーマを1つにまとめたら、二重定義が消えました。

この設計で、型と検証の食い違いによるバグが月6件から0件になり、仕様変更の反映も1箇所で済むようになりました。

スキーマ駆動の3つのポイント
■ 定義を1箇所に
入力の形をスキーマで一度だけ定義
例：const User = z.object({ name: z.string(), age: z.number() })
→ 型もここから自動生成

■ 境界で検証する
外から来る値は入口で必ずparse
例：const u = User.parse(req.body)
→ 通った先は型を信頼できる

■ フロントと共有
同じスキーマをフォーム検証にも使う
→ 表と裏で条件がズレない
効果：二重メンテが消える

実装時の注意点
・parseは境界だけ → 内部で何度もかけない
・エラーメッセージは利用者向けに変換する
・スキーマが巨大化したら分割して共通化

フロントとAPIで検証が二重になっている方は、入口を1つにするだけで保守が楽になります。
#TypeScript #バリデーション #開発効率化

[gon｜テクノスタンダード 代表 @gon_techno]

社内から同じ質問が繰り返し来るとき、効いたのは「ドキュメントをコードの近くに置く」ことでした。
別のツールにまとめると、誰も見に行かないんですよね。
READMEと設計メモをリポジトリに入れて、変更と同じPRで更新する。探しに行かせない、が肝でした。
#開発 #ドキュメント

[gon｜テクノスタンダード 代表 @gon_techno]

CIが1回15分かかっていたのを、3分まで縮めました。
効いたのは「変わった所だけテストする」と「依存のキャッシュ」の2つ。
全部を毎回まわす必要はなかったんですよね。
待ち時間が減ると、小さく出して確かめる回数が自然と増えて、結局それが一番効きました。
#CI #開発効率化 #テスト

[gon｜テクノスタンダード 代表 @gon_techno]

一覧APIが遅い原因、ほとんどがN+1でした。まとめて取る設計に変えたら、クエリ数が1リクエストあたり120回から4回に減りました。

この変更で、一覧ページの応答が1.8秒から0.3秒になり、DBのCPUも目に見えて下がりました。

まとめ取りの3つのポイント
■ 取得をまとめる
IDを集めて一括で問い合わせる
例：loader.load(id) を集約して WHERE id IN (...) に変換
→ ループ内クエリが1回にまとまる

■ リクエスト単位でキャッシュ
同じIDは同一リクエスト内で再取得しない
→ 重複クエリを削減
効果：無駄な往復が消える

■ 境界を意識する
まとめるのはDB・外部APIの境界だけ
→ ドメインロジックは素直なまま保つ

実装時の注意点
・キャッシュはリクエストをまたいで持たない → 古いデータ事故の元
・バッチのサイズが大きすぎるとIN句が重い → 上限を決める
・まず計測でN+1を特定してから入れる

一覧が遅いプロジェクトは、クエリ数を数えるところから始めると原因が一発で見えます。
#パフォーマンス #バックエンド #開発効率化

[gon｜テクノスタンダード 代表 @gon_techno]

開発で効いてるのは、速く作ることより「すぐ戻せる」ようにしておくことでした。
小さく出して、まずければ数分で戻す。
この前提があると、思い切った変更も気楽に試せます。
慎重に大きく作るより、戻せる状態で速く回すほうが、結果的に前に進むんですよね。 #開発 #エンジニア

[gon｜テクノスタンダード 代表 @gon_techno]

PRのレビュー往復、平均4回から1.5回に減りました。やったのは「レビュー観点をPRの説明欄に自分で先出しする」だけ。どこを見てほしいか、なぜこの実装かを3行書いておくと、指摘が本質だけに絞れます。説明を書く手間より、往復が減る効果のほうがずっと大きいです。 #コードレビュー #開発効率化

[gon｜テクノスタンダード 代表 @gon_techno]

自動化して一番効くのは、実は手前の言語化なんですよね。手順を言葉にできていないと、そもそもツールに任せる形にならない。うちでも自動化を進めるほど、暗黙でやっていた判断を明文化する作業が本体だと感じます。仕組み化は言語化が済んだ分だけ進む印象です。

[金ちゃん＠EA作成勉強中 @goldgoldergold]

Claude Codeを使えばバックテストと分析セットでかなり自動化できそう。まだできてないけど。
ただ結局大事なのは手法の言語化。これは変わらないなぁ

[gon｜テクノスタンダード 代表 @gon_techno]

例外を投げる設計をやめて、失敗を戻り値で返すようにしたら、握りつぶしバグが激減しました。

この設計に変えてから、想定外のクラッシュが月8件から0件になり、エラー処理の抜けもレビューで見つけやすくなりました。

Result型の3つのポイント
■ 失敗を型で表す
成功と失敗をひとつの型にまとめる
例：type Result<T> = { ok: true; value: T } | { ok: false; error: E }
→ 呼び出し側が失敗を無視できなくなる

■ 分岐を強制する
例：if (!res.ok) return handle(res.error)
→ 未処理の失敗パスをコンパイラが指摘
効果：握りつぶしが構造的に消える

■ 例外は「想定外」だけに残す
業務エラーはResult、バグ由来は例外で落とす
→ ログの意味が「異常」と「想定内」で分かれる

実装時の注意点
・全部をResultにすると冗長 → 境界（API/外部呼び出し）から入れる
・既存コードは一気に変えない → 新規と修正箇所から段階導入
・ライブラリ導入前に小さく自作でも十分

例外の握りつぶしに悩んでいる方は、まず外部呼び出しの戻り値から試すと効果が見えやすいです。
#TypeScript #設計 #開発効率化

[gon｜テクノスタンダード 代表 @gon_techno]

生成がレビューを追い越す、はまさに現場の悩みどころですよね。コードを後追いで見るより、仕様の側で検証して差分を出す発想は実務的だと思います。認可をデフォルト拒否にして、通したい所だけ人が承認する設計も、事故を減らす筋が良い。

[LangChainJP @LangChainJP]

【Datadogがエージェント向けに構築した仕様検証カーネル「Temper」】

監視・可観測性プラットフォーム企業のDatadogでは、全エンジニアがAIコーディングツールを本番コードに使用し、Claude Codeがその3分の2以上を担っている。同社VP of EngineeringのSesh Nalla氏は、生成速度が人手のレビュー速度を上回り、生成と検証の差に問題が蓄積すると説明した。

この課題に対しDatadogは「Temper」を構築した。エージェントはコードではなく仕様を生成し、Temperのカーネルがその仕様を4層で検証し、検証を通過した仕様をそのままシステムとして動かす。検証は記号推論、到達可能な全状態のモデル検査、障害注入付き決定論的シミュレーション、約1,000本の擬似ランダムな行動列によるプロパティテストで行う。検証対象と実行対象に同じ仕様を使い、両者の乖離を防ぐ設計。

各機能は振る舞い・データ・認可の3契約で記述される。認可はデフォルト拒否で、拒否されたリクエストは人間が承認してポリシーエンジンに動的追加できる。

[gon｜テクノスタンダード 代表 @gon_techno]

ステートレス化で効くのは、運用の"つなぎ目"が減ることだと感じています。セッションを持たない前提だと、途中状態の管理や復旧を別で考えなくてよくなる。管理者承認を一度で済ませられるのも、社内に配るときの摩擦が小さくて、展開のハードルが下がりますよね。

[Hiroki Ebuchi | VERSAROC | AI x UX @vsr_ebuchi]

🤖 MCP 2026-07-28 アップデートの全貌 ── ステートレス化が変える Claude Code 開発の新基準 ⚡
▸ MCP 2026-07-28 アップデート：なぜ「ステートレス化」が革命なのか？
▸ initialize プロトコルと Mcp-Session-Id の廃止
▸ 「管理者承認一回」で済む運用効率の極大化
▶ 記事を読む
https://t.co/ouxS4GkV8J
#AI #DX #開発 #MCP #ClaudeCode