この記事は、太陽光発電とEV充電器の施工を本業とする会社が、どこまでを自分で作り、どこからをメーカーの技術に委ね、どこを人の判断に残しているかを書いたものです。読者として想定しているのは、同業の施工会社、発電事業者や施設の管理者、AIやセキュリティの導入を検討している中小企業、そして「この会社に頼んで大丈夫か」を見極めたいお客様です。製品名と規格名は本文中に明記し、具体的な閾値や内部の設定値は書いていません。

0. 要旨——何を作り、何を取り入れ、何を人が決めるか

I-S3の技術の全体像を一文で言うと、「現場の電気と、Webの暗号を同じ手で扱う会社」です。太陽光発電所の直流配線を引く手と、見積の同意を鍵管理サービスで封印するコードを書く手が同じであることが、この会社の作り方を決めています。

自分で作って動かしているのは、お客様との接点（相談窓口、見積、メール）、自社サイトの守り（ヘッダ、入口の上限、署名付きリンク）、届ける仕組み（翻訳、動画、データ公開）、計算の道具（30分値、反射光、ストリング設計、調査モデル）、そして現場機器と直接話すサーバー（OCPP、Modbus）です。メーカーから取り入れているのは、SolarEdgeのオプティマイザとSafeDC、Tesla Wall Connector、Huawei SmartLogger、OCPP対応充電器といった製品側の技術で、これは11章で分けて書きます。人が決めているのは、金額、施工の可否、広告予算の本適用、公開する文章の最終判断です。

14相談窓口が答える言語の数
4回1通の返信で呼ぶAIの上限（計画・本文・審査・修正）
08:20毎朝、AIが自分に相談して動作を確かめる時刻
0件CSP本適用後のブラウザ違反報告
158デプロイ前に通す回帰テストの件数
5言語サイト本文（日本語正本＋英・越・簡体・繁体）
944枚String Plannerで割付図をPDF化した規模
10万×2調査記事で回したモンテカルロの試行数

1. 相談窓口——14言語で答え、数字は門番が止める自社開発

サイトの相談窓口は、EV充電器の設置、太陽光の自家消費、O&M、採用の問い合わせを受けます。入力された言語を判定し、日本語、英語、中国語（簡体・繁体）、スペイン語、フランス語、ドイツ語、スウェーデン語、ベトナム語、韓国語、タイ語、ヒンディー語、アラビア語、ヘブライ語の14言語で、同じ知識と同じルールに基づいて返します。

1通の返信は一度に書いていません。まず「何を答え、何を聞くか」を内部の構造化データとして計画し、次に短い本文を書き、第三に決定論のチェックと別のAIによる審査で問題を探し、見つかれば修正します。この計画・本文・審査・修正で、1通あたり最大4回AIを呼びます。初回の返信は短く抑え、質問は原則1つにします。相談の1〜2往復目で離脱する方を減らすためです。

数字と型番の門番。返信の中の金額、割合、型番（Tesla、OCPP、SolarEdge、JC-STAR など）を抜き出し、社内で確認済みの知識に無い断定や、お客様の誤った前提への同意を、AIを使わずに正規表現で検出します。見つかれば返信は差し戻されます。AIが「それらしい数字」を作って送ることを、設計として許していません。

写真も受け取ります。分電盤、駐車位置、外壁の写真を送っていただくと、AIが画像を読んで訪問時に確認する論点を絞ります。ここで行うのは見積条件の整理と論点の絞り込みまでで、金額は確定しません。金額と施工可否は現地確認のうえで担当者が決めます（詳しくは「EV充電器の即日施工とAI概算見積はどこまでできるのか」）。

連絡先をいただいた相談は社内に通知されますが、その通知メールには、要望の要約、状況の分析、返信の下書きが付きます。担当者はメールを開いた時点で返信文を持っている状態になり、下書きの生成に時間がかかれば定型文に切り替わるため、通知が遅れることはありません。

2. 自分を点検するAI——毎朝8時20分の相談と週に一度の反省自社開発

相談窓口の品質は、人が時々眺めるだけでは保てません。I-S3では三層の見張りを置いています。

  • 毎朝8時20分、実際に相談を始める。4つのシナリオで本番の窓口に相談を開始し、空の応答、サーバーエラー、社内用語の露出、話題の取り違えがないかを確かめます。新しい版をデプロイした直後にも同じ点検を走らせ、失敗したときだけ通知します。
  • 毎週金曜、12の問いで反省する。直近の会話記録に「お客様の不安を減らしたか」「本当に聞くべき質問は1つだったか」「社内事情が漏れていないか」といった12の問いを当て、確認が必要なものと安全に反映できるものに分けて報告します。連絡先をいただけた割合や、次の行動で終われた割合が下がったときも「要対応」として扱います。この結果は返答ルールの文書へ戻され、次の返信から効きます。
  • 30分ごとの障害監視と、毎週月曜の攻撃分析。AIサービス側の障害や認証エラーを30分ごとに拾い直し、相談窓口に送られてきた攻撃文字列——「以前の指示を無視せよ」といったプロンプト注入、スクリプト挿入、SQL注入——を毎週分類して報告します。

この三層は、ログを後から読む（週次）、障害の記録を見る（30分ごと）、実際に相談を始める（毎朝）という、時間軸も手段も違う三つの目です。どれか一つでは見えない崩れ方があるため、三つを重ねています。

3. 現場知識の索引——ベクトルデータベースを使わないRAG自社開発

相談窓口が答えるために使う知識は、社内のGoogle Driveの文書とスプレッドシートにあります。これを毎時取り込み、公開チャット用、太陽光用、採用用、そして社内専用に分けてプロンプトへ渡します。社内メモの先頭に社内限定の分類を付けておけば、その内容は公開チャットには混ざりません。公開と社内で同じ知識基盤を使いながら、境界を文書側の1行で管理しています。

関連する知識の引き方には、一般的なベクトルデータベースを使っていません。取り込んだ文書を分割し、各断片から製品、機器、地域、制度、組織、手順の6種類の「実体」とその別名をAIで抽出して索引を作ります。回答時はAIを呼ばず、質問文との文字照合だけで関連する断片を引きます。回答時の遅延と費用が増えず、どの断片がなぜ引かれたかを人が追えます。索引が古くなっていれば従来の方式へ自動で切り替わり、文書の変わった部分だけを再抽出します。

4. 見積から発注まで——パスキー署名と鍵管理サービスによる封印自社開発＋Google Cloud

見積書はPDFで送り、お客様は専用ページで内容を読んだうえで発注を確定します。確定の手段は二つで、手書き署名か、スマートフォンの指紋・顔認証による端末の本人確認です。後者はWebAuthn（FIDO2）を使い、登録した端末からの署名（ECDSA P-256 など）を発注ボタンを押す瞬間に再度求めます。氏名を入力しただけでは発注は成立しません。登録の証拠には短い有効期限があり、使い回せません。

署名が成立すると、その時点の書類のハッシュ、署名画像のハッシュ、本人確認の証拠、閲覧の記録を一つの正規化したデータにまとめ、Cloud KMS（Googleの鍵管理サービス）の非対称鍵で署名します。アプリケーション自身は秘密鍵を持たず、署名だけを依頼します。署名済みのデータと証明書PDFは専用の保管場所に置き、後から「どの書類に、誰が、いつ同意したか」を第三者が検証できます。二度押しや同時に開いた複数のタブからの送信は、データベースのトランザクションで1回だけ通します。

担当者が会話の全文や送られた写真を見るためのリンクは、推測できない期限付きのトークンをHMACで署名して発行します。ここで一つ、設計上の約束を置いています。署名用の鍵が設定されていない環境では、リンクを一切発行しない（fail-closed）ことです。この約束がなぜ必要だったかは、12章の教訓に書きます。

5. メール——届ける経路を二重にし、偽装には返信しない自社開発

見積の控え、受付の返信、社内への通知はすべてメールで届きます。送信経路は一つに頼らず、第一の経路（Amazon SES）で送れなければ第二の経路（Gmail API）へ切り替え、両方失敗すれば送信待ちの列に積んで10分ごとに再送します。配送の健全性は30分ごとに確かめ、経路が枯れたときはチャットツールへ通報します。

問い合わせメールへの受付返信は、相談窓口と同じ「計画・本文・審査」の流れで作りますが、送る前に二つの判定を通します。一つは自動送信メールには返信しないこと。不在通知やメーリングリスト由来のメールが持つヘッダ（RFC 3834 の Auto-Submitted など）を見て返信を止め、自社が出す自動返信にも同じヘッダを付けて、返信の無限ループを双方向で防ぎます。もう一つは送信元が認証されていないメールには返信しないこと。受信時の認証結果（SPF、DKIM、DMARC）を読み、差出人ドメインと整合する合格が無ければ自動返信を止め、社内向けの件名にその旨を付けます。差出人を偽装したメールに丁寧に返信してしまうこと——第三者への迷惑メールの踏み台になること——を防ぐためです。

6. サイトを守る——CSP本適用で違反0、入口ごとの上限自社開発

2026年10月10日、サイト全体に Content-Security-Policy を本適用しました。ブラウザが読み込んでよいスクリプト・接続先・フレームを列挙し、それ以外を遮断する仕組みです。手順は、まず報告のみのモード（Report-Only）で約3時間、実際の訪問と全ページ・5言語のブラウザ巡回で違反報告を集め、許可先を5系統補正してから本適用に切り替えました。本適用後の違反報告は0件です。違反報告の受け口は自前で持ち、個人情報が混ざり得るクエリ部分を捨て、送信元の単位で丸めて日別に集計します。

正直に書くと、インライン・スクリプトを許可する設定は残しています。既存ページの多くがインラインで書かれており、一度に外へ出すとサイトが止まるからです。今後ページを更新するたびに外へ出し、最終的に許可を外す計画です。

そのほかの基本も揃えています。すべての応答に HSTS、nosniff、Referrer-Policy、Permissions-Policy を付け、担当者向けリンクとAPIはフレーム埋め込みを拒否し、全経路でHTTPSを強制しています。匿名で送れる見積・訪問・診断・画像の各フォームには送信元のネットワーク単位で上限を置き、超えれば 429 と再試行までの秒数を返します。個別のIPアドレスを状態やログに残さない丸め方にしており、プライバシーへの配慮と、過負荷への耐性を同時に満たしています。送られた画像は拡張子ではなく先頭バイトで形式を判定し、静的ファイルの配信は公開フォルダの外へ出られないことをデプロイのたびに検査しています。

7. 届ける——5言語の本文、3言語の動画、再利用できるデータ自社開発

サイト本文の正本は日本語です。デプロイのたびに、各ページのテキスト部分だけを抜き出し、用語集（社名、代表者名、リパワリングなどの固有の言い回し）を添えて英語・ベトナム語・簡体字・繁体字の翻訳データを生成します。ブラウザ側では、ページの構造を保ったままテキストだけを差し替えます。翻訳データは約2,000ファイルになります。翻訳の検査では、別の文字体系（ハングルやキリル文字）の混入と、人名の誤った音訳を自動で捨てます。住所、提出用の文面、ボタン名のように翻訳してはいけない部分は、翻訳対象外の印を付けて日本語のまま表示します。

動画も同じ考えで、1本の記事につき日本語・英語・簡体字の3本を標準にしています。台本の生成、ナレーションの整形、音声合成、字幕、そして公開前の事実チェック——「昼の太陽光で夜のEVを直接充電できる」のような誤解を招く断言を正規表現で検出する——までを一連の手順にしています。記事とSNSのリンクは表示言語に連動し、英語で記事を開けば英語の動画が埋め込まれます。

調査記事（走行中無線給電の経済性、分散電源のサイバー波及など）では、結論だけでなく、計算モデルのPython、前提のCSV、乱数試行の結果を CC BY 4.0 で配り、schema.org の Dataset として機械可読に記述しています。引用形式（BibTeX）も記事末尾に置いています。第三者が検算し、引用できることが、一次情報としての価値だと考えています。あわせて、AIクローラ向けの llms.txt、サイトマップ、フィードを配信し、デプロイのたびに IndexNow で検索エンジンへ更新を通知しています。

8. 計算する——30分値、反射光、ストリング、モンテカルロ自社開発

AIではない数理処理も、現場の判断を支えています。

  • 30分値の自動解析。電力会社からダウンロードした需要実績のCSVやExcelを貼り付けるかアップロードすると、横持ち・縦持ち・転置の3種類の読み方を同時に試し、最もらしい構造を採用して、日別の統計とヒートマップを返します。読めない場合は「担当者が確認します」に落ちます。原本は保持期限を過ぎると自動で廃棄します。自家消費型太陽光の容量を決める最初の資料です（30分値データの読み方）。
  • 反射光シミュレーション。住所を座標にし、年・傾斜角・方位角・視点の高さ・対象の高さと距離から、年間の反射方向と時刻付きの図、CSVを生成します。近隣への反射光の相談に、設置前に答えるための道具です。
  • I-S3 String Planner。衛星写真や図面を背景にパネルを並べ、ストリングと配線ルートを決め、PDF・JSON・CSVで出力するまでをブラウザだけで完結させる無料ツールです。944枚・16直列×7〜8並列の割付図をPDF化した実例があり、11言語で使えます。
  • 調査記事のモデル。走行中無線給電の経済性では10万回×2のモンテカルロ、分散電源のサイバー波及では2万回の不確実変数の抽選とスイング方程式による周波数のシミュレーションを行い、9つの視点からのRed Teamレビューとその応答表を公開しました。記事内の対話シミュレータ（JavaScript）は研究モデル（Python）と同じ結果を出すことを7ケースで検証しており、読者が前提を書き換えて再計算できます。

9. 現場機器と直接話す——OCPPサーバーとModbusロガー自社開発（規格は業界標準）

EV充電器は、設置して終わりではありません。I-S3は充電器と常時接続して認可・取引・出力配分を行う OCPP（Open Charge Point Protocol）1.6J／2.0.1 の中央システムを自前で書き、Cloud Run 上で運用しています（A-Charge）。充電器との接続は長時間の WebSocket で、施設の受電上限を超えないように複数台への出力配分を計算します。接続時には充電器ごとのトークンを定数時間比較で確かめ、取引IDはプロセスをまたいでも衝突しない乱数にしています。Webページを配る App Engine と分離したのは、Webの再デプロイで充電器との接続がすべて切れることを避けるためです。

太陽光側では、Huawei SmartLogger3000 のメニュー構造に倣ったVirtual Smart Loggerを作りました。RS485経由のModbus RTUでパワーコンディショナのレジスタを読み、ハードウェアが無い環境ではシミュレータで動きます。有効電力制限や無効電力指令のような書き込みは、許可リスト、値の範囲チェック、既定で実行しないdry-run、監査ログの4つを通し、現場で「読んで確かめてから書く」手順を強制しています。これはメーカーの監視装置を置き換えるものではなく、現場でのコミッショニングと点検を自分たちの手順で行うための道具です。

10. RightOS——個人情報を持たずに権利を確かめる自社開発（公開プロダクト）

RightOSは、「この人は有効な権利を持っているか」をQRコードで確認するためのAPIです。店舗の順番待ち、施設の入場、乗り場の整理といった場面を想定しています。設計の中心は個人情報を持たないことで、APIキーはハッシュだけを保存し、Webhookの署名鍵はマスター鍵から導出して保存せず、外部への到達を試みる入力は遮断します。利用者向けの画面は20言語に対応し、API仕様は OpenAPI で公開、AIエージェントから呼ぶための MCP サーバーも提供しています。本番環境に対するライブテストを毎日自動で実行しています。

11. メーカー技術との線引きメーカーの技術

ここまでに書いた仕組みの多くは、メーカーの製品が持つ技術と組み合わさって初めて役に立ちます。混同されないように、どちらが何を担っているかを表にします。

メーカーの技術（I-S3は開発していない）I-S3が担う部分
SolarEdgeのパワーオプティマイザ、SafeDC（停止時にモジュール出力を約1Vへ下げる機能）、モジュール単位の監視人が活動する建物での採用判断、ストリング設計、施工、設定、引き渡し時の停止後電圧の実測と記録、O&Mでの切り分け（DC安全の記事）
Tesla Wall Connector、各社の普通充電器（Wallbox など）分電盤・主幹容量・配線経路の判断、即日施工、現地での見積、Tesla推奨業者としての設置
Huawei SmartLogger3000 とパワーコンディショナ、その Modbus レジスタ仕様現場のコミッショニング手順、Virtual Smart Logger による読取・点検、再起動や設定の手順書
OCPP対応充電器（規格は Open Charge Alliance）中央システム（サーバー）側の実装と運用、施設の受電上限に合わせた出力配分
電力会社が提供する30分値の需要実績形式の自動判別と解析、自家消費容量の算定への橋渡し
Google Cloud の Cloud KMS・Secret Manager・Firestore・Cloud Run、外部のAIサービスのAPI鍵を自分で持たない設計、秘密が無ければ止まる設計、どのデータをどこへ送るかの判断、学習に使われない契約条件での利用

I-S3が新しい技術を積極的に取り入れるのは事実ですが、取り入れることと発明することは違います。I-S3の技術力は、選び、設計し、施工し、設定し、接続し、運用する一連の作業と、その周りで使う道具を自分で作れることにあります。

12. 運用の作法——1本のデプロイ手順と、4つの教訓自社開発

本番への反映は1本のスクリプトで行います。順に、デプロイ先のプロジェクトが正しいかの確認、静的ファイルの配信経路の検査、署名用の鍵が存在するかの確認、翻訳データの生成、FAQ・地域ページ・事例ページの生成、公開記事の文体検査、サイトマップの生成、古い版の削除、デプロイ本体、ドメインの確認、知識の同期、配送の健全性確認、新しい版での相談窓口の自己レビューと動作点検、検索エンジンへの通知です。回帰テストは158件あり、設定ファイルとコードでセキュリティヘッダの内容が食い違えばテストが落ちます。

  1. 確認 — デプロイ先プロジェクトの一致（過去の事故の再発防止）
  2. 検査 — 静的ルート検査／署名鍵の存在／公開記事の文体検査
  3. 生成 — 翻訳JSON（4言語）／FAQ／地域LP／事例／サイトマップ
  4. デプロイ — gcloud app deploy（プロジェクト固定）／古い版の削除
  5. 点検 — 相談窓口を実際に開始（4シナリオ）／版境界の自己レビュー／配送ヘルス
  6. 通知 — IndexNow／Search Console

運用の作法は、失敗から決まりました。読者の役に立つように一般化して、4つを書きます。

教訓1：秘密が無いなら、弱い代替で動かすな。止まれ。署名付きリンクの鍵が本番で未設定のまま、コードは「公開されている識別子から導いた値」を代わりの鍵として使って動き続けていました。リンクは発行され、動いて見え、誰も気づきませんでした。点検で見つけた後、代替を廃止し、鍵が無ければ発行しない設計（fail-closed）に変え、過去に発行したリンクは意図的にすべて失効させました。「動いている」は「安全に動いている」の証拠にはなりません。

教訓2：やめた事業者の鍵に、何本が依存しているかを数えろ。メール送信の事業者を一つやめた後も、お客様宛の2通（受付返信と見積の控え）がその経路専用のまま残り、不達になっていました。さらに社内通知11本の「送れるかどうか」の判定が、やめた事業者の鍵の有無を見ていました。鍵を一つ消した瞬間に全部止まる構造を、鍵を消す前に洗い出す手順を加えました。

教訓3：同じ認可のトークンを二つの場所で更新するな。SNSへの自動投稿で使う更新トークンを、手元の環境とサーバーの定期処理がそれぞれ別に保管・更新していました。あるとき手元側の保存が名前解決の不具合で静かに失敗し、サーバー側が古いトークンで更新を試みた結果、認可全体が失効しました。保管先を一本化し、保存に失敗したら理由を必ず表示するように直しました。静かに失敗する処理が、いちばん高くつきます。

教訓4：ライブラリの「黙って切る」は、基盤の「不健全」になる。充電器と接続する WebSocket サーバーで、使っていたライブラリが WebSocket 以外のHTTPリクエストを応答なしで切断していました。実行基盤の健全性確認がそれを「不健全」と判定し、全面的に接続を拒否する障害になりました。HTTPの解釈部分を差し替えて解消しましたが、学んだのは、基盤の健全性確認が何を送ってくるかを、自分のサーバーが何を返すかと突き合わせておくことです。

4つに共通するのは、障害を「直して終わり」にせず、回帰テスト、設計ルール、手順書のどれかに変換したことです。158件のテストのうち36件は、2026年10月の点検で加えたものです。

13. やっていないこと、まだ検証中のこと

  • AIは金額を確定しません。相談窓口も写真の解析も、条件の整理と論点の絞り込みまでです。金額と施工可否は現地確認のうえで人が決めます。
  • 広告の予算変更を自動では本適用しません。週次のレビューが改善案を出し、自動で変えられる幅に上限を置き、本適用には人の確認を必要としています。
  • 公開チャットの内容は学習に使われません。外部AIサービスのAPIは、送信内容をモデルの学習に使わない契約条件で利用しています（プライバシーポリシー）。
  • 手元で動く小型言語モデルは検証中です。問い合わせの分類や翻訳の比較を小型モデルで試していますが、本番の経路には載せていません。本番で使う推論はサーバー側で動くものに限る、という方針で設計しています。
  • CSPのインライン許可は残っています。6章に書いたとおり、ページの更新に合わせて外していきます。

技術の紹介記事に「やっていないこと」を書くのは、できることの範囲を正確に伝えるためです。できることを大きく見せるより、どこで人が判断しているかを明らかにするほうが、お客様にも同業者にも役に立つと考えています。

よくある質問

AIチャットが見積金額を出すのですか。

出しません。チャットが行うのは、見積に必要な条件の整理と、訪問時に確認する論点の絞り込みまでです。金額と施工可否は現地確認のうえで担当者が決めます。回答に含まれる数字や型番は、社内で確認済みの知識に無ければ送信前に差し戻されます。

チャットに書いた内容はAIの学習に使われますか。

使われません。回答生成には外部のAIサービスのAPIを利用しますが、送信した内容を各事業者がモデルの学習に使わない契約条件で利用しています。詳細はプライバシーポリシーに記載しています。

見積の署名にパスキー（指紋・顔認証）が使えない端末ではどうなりますか。

手書き署名で発注を確定できます。手書き署名と端末の本人確認のどちらかが必須で、氏名の入力だけでは成立しません。署名した時点の書類と証拠は鍵管理サービスの鍵で封印し、後から検証できる形で保管します。

ここで紹介している仕組みは他社でも使えますか。

RightOS（権利確認API）とString Planner（太陽光ストリング設計ツール）は公開しており、どなたでも使えます。調査記事の計算モデルとデータはCC BY 4.0で公開しています。それ以外の社内の仕組みは、設計の考え方と採用した規格を本文で説明しています。同じ構成を自社で組みたい方からの相談も受けています。

SolarEdgeやTeslaの技術はI-S3が開発したものですか。

違います。SolarEdgeのSafeDCやオプティマイザ、Tesla Wall Connector、Huawei SmartLogger、OCPP対応充電器は各メーカーの技術です。I-S3が担うのは、それらの選定・設計・施工・設定・接続・運用と、その周りで使う自作のツールです。11章に表で整理しています。

この記事に出てきた仕組みを、実際に試す

相談窓口は14言語で動いています。EV充電器や太陽光のご相談はもちろん、「同じ構成を自社でも組みたい」「見積の電子署名の仕組みを詳しく聞きたい」といったご相談も受け付けています。数字と型番は門番が確かめてから返しますので、答えられないことは「答えられない」と返ります。

相談窓口を開く 担当者に直接連絡する

関連ページ

本記事は2026年10月10日時点の本番運用の内容に基づきます。採用している規格と製品の名称は各権利者に帰属します。閾値、内部の設定値、鍵や識別子の名称は、安全のため記載していません。記載内容は運用の変更に伴って更新します。