生成AIで伸びるIT企業、
取り残されるIT企業。

生成AIの導入を決める前に、システム開発事業の変化を見極める

シルエルは「生成AIで開発すること」を前提にしません。顧客企業がAIを利用し始める可能性、試作の容易化、開発成果物への説明責任の変化などを、確定した未来ではなく検証すべきシナリオとして扱います。

経営者の問いを、現場で検証できる課題に変える

経営戦略の代行や売上保証ではありません。経営者と現場責任者が持つ問題意識を、業務・顧客・技術・人材の観点から整理し、検証可能な仮説に落とし込みます。

業務の理解から、開発と運用の進め方を見直す

新しい開発ツールを入れることより先に、何が業務上の問題なのかを明らかにします。シルエルが培ってきた業務モデリング、要求分析、作法の抽出を活用する領域です。

FDEだけを育てても、開発会社は変わらない

技術者の役割は一つではありません。顧客課題を捉える人、設計・実装する人、品質を保証する人、既存資産を維持する人、チームを統括する人。それぞれの能力を組み合わせます。

10講座を、会社の課題に応じて組み合わせる

これまで検討してきたT1〜T10の研修体系です。全講座を一括導入する必要はありません。対象職種と現場課題に応じて選択し、実案件演習につなげます。

10講座合計152時間のカリキュラム案。内容・実施時間は契約時に調整します。全講座の実施や認定資格の付与を約束するものではありません。

「AIが合格と言った」を、検証結果にはしない

開発したLLMが、自分でテスト条件を作り替え、合格を報告する構造は避ける必要があります。シルエルは、品質保証をLLMの自己申告から切り離すための運用・技術設計を支援します。

顧客が自ら確かめられる、開発と検収の仕組み

顧客が検証用LLMを独立して契約・管理し、顧客の受入条件に基づいて確認するモデルを検討しています。シルエルが提供するのは、検証環境と運用・契約上の論点を整理する支援です。

研修の成果を、担当者が替わっても使える能力へ

人が学ぶだけでは、異動や退職で知識が失われます。逆に、記録を大量に保存するだけでも、組織が学習したことにはなりません。現場の判断とその根拠を、次の案件で再利用できる状態を目指します。

キクエル・ミルエルは、経営判断を代行する道具ではありません

シルエルが研究・開発してきた技術を、必要に応じて実証に利用します。これらをすべての顧客に導入することがコンサルティングの前提ではありません。

※ キクエル・ミルエルなどの利用可能範囲・実装状況・ライセンス条件は個別に確認します。すべてが即時提供可能な完成品であることを意味しません。

シルエルが担うこと、担わないことを明確にする

相談の入口を広げるために、提供できない業務まで「サービス」とは記載しません。案件ごとに支援範囲、担当者、成果物、検証方法を合意します。

必要に応じて弁護士、公認会計士、経営・人事の専門家などとの協働を前提にします。専門家の紹介や手配は個別に協議します。

診断・設計・実証・定着を、必要なところから

期間や費用は対象業務・参加人数・検証環境によって変わります。3か月や6〜12か月を固定の商品として保証するものではありません。

何を納品するかを、最初に合意します。

契約する支援メニューによって成果物は異なります。すべてを一括で提供するものではありません。