こんにちは！株式会社雲海設計の技術部です。 生成AIを業務に入れた会社が次にぶつかる壁。それは「請求が読めない」問題です。 月末の請求が「想定の2〜5倍」になる 使えば使うほど価値は出るのに 原価が読めずに止まる 予算を守ろうとして利用制限 → 現場が回らない この状況、システム開発でいうと「見積もりが崩壊する事件」と構造が同じです。 犯人は“技術力不足”ではなく 設計と運用（＝原価管理）の不在 。 今回はトークン課金を「経費」ではなく原価として扱える形に落とす、現実的な方法を解説します。 事件現場：なぜ請求が“読めない”のか 1) トークンは「従量課金」だが、従量の中身が増殖する トークンはテキスト処理の最小単位で入力（prompt）と出力（completion）で別々にカウントされます。 つまり料金はざっくりこうです。 料金 ≒（入力トークン×入力単価）＋（出力トークン×出力単価）＋（付帯コスト） しかし現場では入力トークンが静かに肥大化します。 典型が「会話履歴の積み上がり」と「長大なシステムプロンプト」です。 FinOps...

こんにちは！株式会社雲海設計の技術部です。 「当初の見積もりは500万円だったはずが最終的に1500万円に。半年で終わるはずのプロジェクトが1年経ってもまだ終わらない…」 これはシステム開発の現場で決して珍しくない「事件」です。 実際、開発経験者への調査では 納期に関するトラブル・失敗が「よくある／時々ある」と答えた人が7割超 、 予算に関するトラブル・失敗も半数近く にのぼります。 さらに別の調査では「問題の根本要因」は要件定義（55%）・設計（51%）など前工程に集中しています。 なぜこのような「事件」が繰り返されるのでしょうか？ この記事では読者の皆様に「探偵」になっていただき、システム開発プロジェクトを破綻させた「犯人」を一緒に突き止めていきたいと思います。現場に残された証拠（データ）を元に、5人の容疑者を徹底的に洗い出していきましょう。 事件現場：A社・新顧客管理システム開発プロジェクト 被害状況：見積もり3倍、納期2倍 当初の見積もり：500万円 / 6ヶ月 最終的なコスト：1500万円 / 12ヶ月 事件の概要 Excelでの顧客管

こんにちは！株式会社雲海設計の技術部です。 「AIエージェントが自律的にタスクをこなし生産性を劇的に向上させる」— そんな未来像に期待が寄せられる一方、厳しい現実があります。 Forbes JAPANなどで紹介されたMIT（Project NANDA）の調査では、企業の生成AIパイロットの多くが本番価値に結びつかず成功は一部にとどまると報告されている。 多くの開発現場ではこの失敗の原因をモデルの性能やプロンプトの工夫不足に求めがちです。 しかし真の問題はもっと根深い部分、すなわちシステムの「設計思想」そのものに潜んでいます。 本記事ではプロのエンジニア視点からなぜ多くのAIエージェントプロジェクトが失敗するのか、その「本当の理由」を解き明かします。 そして複雑なフレームワークに頼るのではなく「シンプルな設計」こそが成功の鍵であることを、AI開発のトップランナーであるAnthropic社の設計原則を交えながら5つの具体的な原則として提示します。 幻想に終わる「万能エージェント」と 95%が陥る4つの罠 多くの失敗プロジェクトに共通するのは「あらゆ

こんにちは！株式会社雲海設計の技術部です。 いきなり強い言葉で始めます。 本番に入るコードにテストがないのは、エンジニアとしてあり得ません。 ただし誤解してほしくないのは 「すべてのコードにテストを書け」と言いたいわけではない ということです。現実にはテストに時間を割く合理性が薄いケースもあります。 たとえば、 一度きりのデータ移行スクリプト（実行後に捨てる前提） 技術検証のためのPoC（実現可能性の確認が目的） 本番に一切影響しない、完全に隔離された調査用コード こうした「書き捨て」が前提のものは、テストよりも 実行手順のレビュー や リハーサル のほうが費用対効果が高いこともあります。 しかし、 本番環境にデプロイされるコード 事業に影響する変更 お客様のデータを扱う処理 ここにテストがないのは、やはり「あり得ない」。 理由はシンプルでこれは品質論ではなく 経営判断としても損 だからです。 テストがないのは「品質が低い」ではなく「損失が増える」 「テストは品質を上げるもの」と思われがちですが、本質は違います。 テストは未来に起こる損失を減らす

こんにちは！株式会社雲海設計の技術部です。 「見積もりと実際の工数が2倍以上ズレた」 「リリース直前に"これじゃない"と言われた」 「テスト段階で想定外の仕様が続出した」 開発プロジェクトに関わったことがある方なら、こうした経験に心当たりがあるのではないでしょうか。 手戻り、納期遅延、品質事故。 これらの多くは 要件の曖昧さ が原因の一つとして挙げられます。 「要件は固まっていますよ」と言われて受け取ったドキュメントを開いてみたら、肝心なところが「後で決める」「要相談」だらけ。結局、開発が始まってから仕様を詰めることになり、当初の見積もりは意味をなさなくなる——こんな光景は意外と珍しくありません。 いきなりですが、30秒だけお時間をください。 以下5問に Yes / No で答えるだけで、あなたのプロジェクトが「炎上予備軍」かどうか分かります。 【30秒診断】あなたの要件は事故りませんか？ 次の5問に Yes / No で答えてください。 Yesが2つ以下なら、今のまま着手すると高確率で手戻りが出ます。 目的（なぜ作るか）を1文で説明できる...

こんにちは！株式会社雲海設計の技術部です。 この記事は 現場責任者（部門長・チームリーダー・業務改善担当）  の方に向けて書いています。 「Excelでの管理、正直キツくなってきた…」と感じつつも、システム移行の稟議を通すほどの根拠がない。 かといって、このまま放置して事故が起きたら自分の責任になりかねない——そんなモヤモヤを抱えている方が対象です。 本記事を読むことで 「移行すべきか・継続でいいのか」を感覚ではなく定量で判断し、社内で検討を開始するための材料 が手に入ります。 この記事の結論 Excelは万能ではないが悪でもない。 「規模」「頻度」「関係者数」で最適解は変わる。 5つの観点（同時編集・監査ログ・権限・参照整合性・障害復旧）で スコアリングすれば移行判断は"数字"で語れる 判定結果が「システム化優先」でも、いきなり大規模開発は不要。 まずは要件整理から始めれば手戻りなく進められる。 Excel限界スコア診断（Yes/Noで判定） まずは直感で答えてみてください。所要時間は約5分です。 テキストフローチャート 【START】そのEx

こんにちは！株式会社雲海設計の技術部です。 最近「AIを業務に導入しました！」という声をよく聞くようになりました。 チャットで質問に答えてもらったり、文章の下書きを作ってもらったり——便利ですよね。 一方で導入が進むほど増えるのがこの不安です。 「AIが勝手に実行してしまわない？」 「誤送信や誤更新が起きたら取り返しがつかないのでは？」 「どこまで任せて、どこから人が見るべき？」 この記事ではAIを“怖いもの”から“使いこなせる道具”に変えるための考え方として、 AIのガードレール設計（権限と承認の設計） を解説します。読み終える頃には、自社で「任せる範囲」と「人が確認すべき範囲」を線引きするための具体的な型が手に入ります。 そもそも「AIの実行権限」って何ができるの？ ここで言う「実行権限」とは、 AIが呼び出せる外部ツールにどの範囲の権限を付与するか を指します。 （例）メール送信、請求書確定、顧客情報の更新、SaaSへの登録、チケット起票、権限変更…など これまでのAI活用は「提案」までが中心でした。 「この文章どう？」→「こういう案はいか

こんにちは！株式会社雲海設計の技術部です。 最近、お客様との打ち合わせで「うちもAIを開発に取り入れたいんだけど…」というご相談をいただくことが増えました。ChatGPTなどの生成AIの話題を目にしない日はありませんよね。 でも正直なところ「AIを導入したけど思ったほど効果が出なかった」「むしろ混乱が増えた」という声も耳にするようになりました。 もし「AI駆動開発に興味はあるけど、うちでうまくいくのかな…」と感じている方がいらっしゃったら、ぜひこの記事を読んでみてください。この記事を読み終える頃には「失敗する会社に共通するパターン」と「自社で気をつけるべきポイント」がクリアになっているはずです。 そもそも「AI駆動開発」って、何ができるの？ 「AI駆動開発」という言葉、なんだか難しそうに聞こえますよね。 すごくシンプルに言うと「AIをアシスタントとして使いながらソフトウェアを作ること」です。 たとえばこんなイメージです。 新人社員に「この書類のフォーマット作っておいて」とお願いするように、AIに「こういう機能のプログラムを書いて」と指示を出す。す

こんにちは！株式会社雲海設計の技術部です。 突然ですが、こんな経験はありませんか？ 「半年前に自分で書いたコードを見たら、何をやってるのか全然わからなかった…」 「他の人が書いたコードを引き継いだけど、どこを直せばいいのか見当もつかない…」 開発現場では残念ながら「クソコード」という言葉が飛び交うことがあります。 もちろん誰も最初からそんなコードを書こうとしているわけではありません。 でも時間に追われて急いで書いたコードやとりあえず動けばいいと妥協したコードは気づけば誰にも読めない「 負の遺産 」になってしまうんです。 もし「うちの開発チームのコード正直ちょっと心配かも…」と感じている方や「もっとスムーズに開発を進めたいのになぜか時間がかかる」と悩んでいる方がいらっしゃったら、ぜひこの記事を読んでみてください。 この記事を読み終える頃には なぜコードの読みやすさが会社の生産性を左右するのか 、そして どうすれば「クソコード」を生まない開発体制を作れるのか が見えてくるはずです。 そもそも「リファクタリング」って何ができるの？ 「リファクタリング」

こんにちは！株式会社雲海設計の技術部です。 「アプリを作りたいけど、全部プログラミングしないとダメなの？」「最近よく聞くノーコードって、結局どこまで使えるの？」——そんな疑問を持ったこと、ありませんか？ 特にこれからエンジニアを目指す方やシステム導入を検討している経営者の方にとって「どこまで自分で作るべきか」という判断はなかなか難しいものですよね。 もし「プログラミングを全部覚えなきゃいけないの？」と不安に感じている方や「ノーコードで済むなら楽だけど、ちゃんとしたものが作れるか心配…」と迷っている方がいらっしゃったら、この記事はきっとお役に立てます。 この記事を読み終える頃には ノーコードと手書きコード、それぞれの「得意分野」がスッキリ分かり自分のプロジェクトにどちらを選べばいいか判断できるようになっている はずです。 そもそも「ノーコード」と「フルスクラッチ」は何ができるの？ まず、この2つの違いを整理しておきましょう。 ノーコード とはすごくシンプルに言うと 「プログラミングなしでアプリやWebサイトを作れるサービス」のことです。...