プロジェクトを始める前に、
気になる点を確認しましょう。

アイデアだけがある初期の段階、要件を整理している段階、既存の提案依頼書や企画書をレビューしている段階のいずれでもご相談いただけます。初回相談では、現在の運用と変えたい課題を確認し、必要な調査と優先順位を整理します。

既存の画面と機能、コンテンツの構成、運用の方法、連携しているシステムを確認し、再利用する部分と設計し直す部分を切り分けます。主な問題が特定の業務フローにあれば部分改善を、構造的な制約が複数の領域にまたがっていれば段階的な全面刷新をご提案できます。

業務への影響と技術的な依存関係を踏まえて、画面、機能、データ、連携の領域を切り替えの単位に分けることができます。既存システムを運用しながら新しい機能をAPI（システム同士がデータをやり取りするための窓口）でつなぎ、検証が済んだ領域から順に切り替える方法と、段階ごとの点検基準をあわせて設計します。

目標、必要な画面と機能、ユーザーの種類、既存システムとの連携、データ移行の有無、ご希望の運用方法をお知らせいただくと、範囲を具体化しやすくなります。スケジュールと費用は、これらの内容を検討し、優先順位、検証の範囲、成果物について合意したうえでご提案します。

お問い合わせフォームで［お問い合わせを送信］を押すと、すぐに受付が完了して担当者にメールで届き、お問い合わせの記録として保管されます。受付が完了しなかった場合は、画面の案内に沿って、メールの下書きまたはお電話でお問い合わせいただけます。

連携先が提供するAPI（データをやり取りするための窓口）、データベースへのアクセス条件、認証方式、呼び出しの制限をまず確認します。古いシステムでは、直接つなぐよりも中継APIやバッチ処理（決まった時刻にまとめて一括で処理する方式）が適している場合があり、実際の環境と担当部署のポリシーに合わせて連携の構成を決めます。

ユーザーの役割と業務フローを整理する企画から、情報設計、画面設計、ビジュアルデザイン、レスポンシブ対応の実装まで一貫して対応できます。社内の企画案やデザインシステムがある場合は、それを基準に必要な領域だけを担当することも可能です。

範囲に応じて、要件、画面フロー、UIデザイン、システム構成、API定義、ソースコード、テスト結果、運用マニュアルなどをまとめます。必要な成果物とその形式、記載の詳しさは着手前に合意します。これらはプロジェクトの性格によって異なる場合があります。

元データの構造と品質、移行先システムのデータモデル、個人情報の取り扱いと保存に関するポリシーを確認したうえで、移行の範囲を決めます。サンプルデータを使って変換ルールと検証基準を先に確認し、エラー処理や切り替えのタイミングまで計画に含めます。

無償修正、障害対応、定期点検、機能改善のように性格の異なる業務を区別し、必要な運用範囲を協議します。対象システム、対応時間、本番反映の手順、担当者の役割、依頼の処理方法を確認したうえで、保守の範囲として別途まとめます。

Web標準とWebアクセシビリティ、複数のブラウザーで画面が同じように表示されるか（クロスブラウザー対応）は、企画の段階からあわせて確認します。案件に適用するアクセシビリティ基準がある場合は、段階ごとの確認項目と検収の方法を、要件に合わせて決めます。

対応の方法は、保守の範囲を決める際にあわせて協議します。協議では、障害がサービスに与える影響に応じてレベルを分け、レベルごとに初動対応と復旧目標、報告の方法、業務時間外の連絡経路を決めて運用資料に残します。

ダッシュボードを見てどのような判断をするのか、誰が見るのか、指標ごとの計算方法と基準日、データソースと更新頻度を先に決めます。指標の定義について合意できたら、画面は概要から詳細へと掘り下げていく問いの順序に合わせて構成します。

繰り返しの頻度、入力データの形式、期待する結果を確認できる基準、例外的な状況と人が判断するポイントを見ていきます。効果を確かめやすい小さな業務を優先して選び、AIが担う部分と既存のルールで処理する部分を切り分けます。

RAGは、質問に関連する社内文書を検索し、その内容を言語モデルが回答する際の文脈として渡します。文書名や該当箇所などの出典を回答とともに表示するよう設計でき、検索で見つからなかった内容についての回答の制限と、担当者による確認の手順も定めます。

業務への適合性を確かめるには代表性のあるサンプルが必要ですが、最初からすべてのデータをご提供いただく必要はありません。データの所有と利用の権限、機微な情報が含まれるかどうかを先に確認し、匿名化や代替サンプルを使う方法を検討します。

限られた業務とデータで、モデルが必要な結果を出せるか、担当者が結果を確認・修正しやすいか、システム連携にどのような制約があるかを確認します。評価の質問と基準を先に決め、結果をもとに拡大、見直し、中止のいずれにするかを判断します。

AIの結果をそのまま確定値として使うのではなく、出典、信頼できる条件、例外の表示、人による確認の段階を業務の重要度に合わせて設けます。運用中の修正と失敗の履歴を残し、繰り返し起きる誤りは、データや検索ルール、プロンプト（AIに与える指示文）、業務フローの改善項目として管理します。

導入前にお客様と一緒に決める項目です。文書や質問・回答の記録をどの環境に保管するか、外部の言語モデルを使う場合はどの情報をどこまで渡すか、個人情報や機微な資料を渡す前に伏せるか除くか、記録を誰がいつまで閲覧できるかを確認します。決めた基準は設計書に残し、運用ポリシーが変わった場合は改めて検討します。

導入前にお客様と一緒に決める項目です。撮影の目的と範囲、告知の方法、元の映像と解析結果の保存期間、閲覧権限について、関連法令と社内のポリシーに沿って、お客様の組織で個人情報を担当する部署と協議します。目的に必要な集計結果だけを残す、画面上で顔を隠すといった、扱う情報を減らす構成もあわせて検討します。

中央省庁と公的機関のシステムインテグレーション（SI）案件を手がけてきました。民間クラウドを基盤とした国民向け広報Webサイト、公団（公的法人）の統合精算・決済システム、区（基礎自治体）の公式Webサイト、公共図書館のデジタル資料室システムなど、市民が利用するWebサイトと機関の業務システムを開発しました。お客様の情報を保護するため、機関名や数値は掲載していません。

公共分野や企業で広く検証されてきた標準技術で、画面、業務サーバー、データベースを構成します。保守を担う人材を確保しやすいか、長く運用できるかを基準に選び、具体的な構成は既存システムと運用環境を確認したうえで提案書に明記します。

カード会社・保険会社の電文送受信システムでは、安全な通信とデータの暗号化、送受信のモニタリングとログ管理を実装しました。決済端末とVAN（カード決済の承認を中継する付加価値通信網）を連携する精算システムでは、Web脆弱性診断によって個人情報のリスクを減らし、セキュリティを強化しました。新しいプロジェクトでも、権限、データ保護、ログの基準を設計段階で一緒に決めます。