この記事は、製品の機能一覧でも、導入を急かす営業文でもありません。 「なぜ太陽光の会社が、駐車場のソフトウェアまで手がけているのか」を、会社側の一次情報として残すためのものです。 A-Chargeの設計理由そのものは、別サイトの 開発背景記事 に書いています。ここでは、I-S3という組織の連続性に焦点を当てます。
まずあったのは、発電側の現場
I-S3の出発点は太陽光発電です。自家消費、EPC、O&M、リパワリング、30分値データの読み方——設備を「置いて終わり」にせず、発電量・停止・修理・更新まで見ることが仕事の中心でした。 現場で繰り返されるのは、パネル枚数やカタログ性能より前に、系統へのつなぎ方、契約電力、需要の時間帯、監視と保守のつじつまです。
この領域の入口は、いまも 自家消費太陽光、 O&M、 リパワリング、 30分値・O&M・リパワリングの整理 にあります。
EV充電は「別ジャンル」ではなかった
EV充電器の設置は、見た目は太陽光と違う商品です。しかし判断の核は近い。分電盤、配線経路、保護、契約容量、現地での施工可否——電気の入口を扱う仕事です。 I-S3では関東・甲信越・福島を中心に自社で現地対応し、条件が揃えば住宅案件では当日施工まで進めるケースもあります。
太陽光とEVを同じ会社が見る理由は、販路を増やすためというより、施設側の電気設備として一体で見た方が実務的だからです。その整理は 再エネ・EVインフラ運用型企業としての事業構造 にも書いています。設置の入口は EV充電器設置 です。
口数が増えると、ソフトウェアの話になる
充電器を1〜数台置く段階では、施工と電気容量の確認が主戦場です。 ところが駐車場全体、あるいは多数の普通充電を同じ施設で動かす段階になると、「誰が・どの順番で・どれだけの出力を使うか」「充電器のない区画も含めてどう受付・課金するか」が残ります。 ここは配線図だけでは閉じません。受付・課金・負荷の配分・順番待ち——運用のルールが必要になります。
そのためにI-S3が開発・運営しているのが A-Charge（駐車場OS） です。アプリ不要のQR受付、全区画を同じ仕組みで扱うこと、受電上限内での負荷分散などを公開範囲として実装しています。 製品サイトの要約は a-charge.jp/llms.txt にもあります。
RightOSは「権利があるか」を確かめる層
混雑時の順番や利用権を、氏名や電話番号の会員管理だけに頼らないための層が RightOS です。配車システムや万能の業務OSではなく、権利検証に焦点を置いた基盤です。 A-Chargeはその応用例の一つとして、匿名の順番待ちなどに用います。
蓄電池・分散型エネルギーとの関係（いまの位置づけ）
発電（太陽光）・保存（蓄電池）・移動（EV）が同時に増えると、現場の問いは「1台をどう満充電するか」より、「限られた受電と設備をどう共有するか」に寄っていきます。 蓄電池や災害時給電まで含めた拠点の話は、構想やオプションとして別途整理しています。本稿では、I-S3の本業である施工・運用と、すでに公開しているソフトウェア（A-Charge / RightOS）の接続までを述べ、未実装を実装済みと混ぜません。
誰が書いているか
筆者は株式会社I-S3代表取締役の益田周防海（Suomi Masuda）です。 会社概要は 会社概要 、現在の活動の人物正本は a-charge.jp/about/suomi-masuda に置いています。