非エンジニアが、AIを本気で使うと
ここまでできる。
非エンジニア出身です。今はAI(Claude Code / Codex)を主戦力に、要件定義から実装・運用まで一人で回しています。
事業の軸は3つあります。顧客向けの業務システム開発・Web制作の受託。自社の業務自動化ツールの内製(17件以上)。そして、AIに自分自身の判断軸を渡して活用する仕組みの研究開発です。
技術と非技術の境界を自分で越え、法務・営業・デザイン・インフラ運用まで一人で担当する働き方を続けています。
HGJ合同会社 代表
要件は、
言われた通りには作りません。
非エンジニア出身。AI(Claude Code / Codex)を主戦力に、要件定義から実装・運用まで一人で回しています。口頭の要望をそのまま形にする前に、実発言や一次情報まで遡って前提を検証してから作ります。
「何が欲しいか、うまく言えない」まま
発注先を探していませんか。
大手に頼むには話が重すぎる。かといって、フリーランス一人に丸投げするのも不安が残る。
要件定義書を書けるほど、自社の業務は整理されていない。でも、動くものは早く欲しい。
そういう状態のまま「とりあえず言った通りに作ってください」と発注すると、たいてい後から前提のズレが見つかります。
非エンジニアが、AIを本気で使うと
検証してから作る、という姿勢を体現した一例です。
4枚 vs 7枚。
多いほうが、正確とは限らなかった。
手書き作業日報のOCR連携ツールで、時刻欄の“0”と“2”(19:15→18:15など)の誤読が頻発していました。
原因は「1枚まるごと読ませる」設計で、該当欄の解像度と文脈情報が不足していたことでした。
該当欄だけを拡大クロップし、同じ作業員の過去の正解例をお手本として見せる方式に変更。お手本の枚数を7枚と4枚で実測比較したところ、4枚構成のほうが正答率が高いという結果になりました(4枚構成5/7正解、7枚構成3/7正解)。
「モデルを大きくする」よりも「該当箇所を拡大する」「正しい例を毎回見せる」の組み合わせが効く、という実務的な学びでした。お手本は多いほど良いわけではありません。
自社の業務も、
同じやり方で自動化しています。
自分の手作業を見つけ次第スクリプト化する習慣があります。日次・週次で無人稼働しているツールは17件以上。
- 手書きOCR × 基幹システム連携稼働中
- 議事録自動化ツール群稼働中・複数系統
- シフト表OCR自動化稼働中
- 資金繰りダッシュボード銀行/カード明細統合
- 監視ツール(自動化ジョブの死活監視)自社開発
- 議事録自動化ソフトの商品化開発完了・販売準備中
業種は固定していません。
医療、金融、店舗、ECなど、案件ごとに異なる業界知識をそのつどリサーチして対応しています。
医療機関の予約自動化金融業務システム店舗Web制作 / SEO・MEOEC・業務効率化
失敗は、隠さず書きます。
うまくいった話だけ並べても、判断の材料にはなりません。実際に止まったこと、直したことをそのまま書いておきます。
ローカルLLMの実機フリーズ事故
自社サーバーで動かしていたAIモデルを上位版に切り替えたところ、想定していた挙動にならず、サーバー全体が応答しなくなりました。物理的な再起動で復旧。以後、モデルの切り替えは「動くはず」で進めず、必ず実機での再現テストを挟むようにしています。
デザイン全面リセットの決断
ある案件で、6ページ分作り込んだデザイン一式が完成度は上がっていたものの、自分の品質基準に納得できませんでした。削除はせず旧一式を退避したうえで、業種特化の素材制作からやり直しました。
原因不明の事故は、正直に「未特定」と書く
自社ソフトウェアの開発中、データ消失事故が発生しました。原因を無理に断定せず、判明している事実と未特定の範囲を分けて記録し、再発防止策を先に実装しました。
開発完了・販売準備中
議事録の自動化を、
ソフトウェアにしました。
自社で使っていた議事録自動化ツールを、買い切りソフトウェアとして商品化しています。ライセンス認証・利用規約・販売ページまで自社設計。macOSネイティブAPIを使い、会議へのBot参加を必要としない方式に設計を切り替えた経緯もあります。
協業・業務提携のご相談も歓迎します。
受託開発だけでなく、AIを使った業務設計や、自社ツールの共同開発についてのご相談もお受けしています。
依頼の流れ
01
まずは相談
要件が固まっていなくて構いません。現状と困りごとを聞かせてください。
02
前提の検証
口頭の要望をそのまま実装せず、必要であれば一次情報まで確認してから設計します。
03
実装・運用
要件定義から実装、必要なら運用の自動化まで一人で担当します。