# TechJapan LLC — main English pages, in one file A snapshot bundle of 13 pages from https://www.tech-japan.jp, each as the Markdown version of its page. Not a source of truth: the facts are in https://www.tech-japan.jp/facts.json and each page is at its own URL. Generated 2026-10-14. --- source: https://www.tech-japan.jp/ markdown: https://www.tech-japan.jp/index.md updated: 2026-10-14 # We build ontology platforms. *The part that has to be right before the model matters.* For companies whose AI answers confidently and wrongly. The cause is almost never the model — it is that the same concept has four names and nobody ever wrote down how they connect. We fix that layer, then build retrieval that can point at the passage it used. Our own software runs on it: **Hadano AI Cabinet**, alongside three products in production. ## What TechJapan LLC is An ontology platform developer. We are a small company in Hadano, Kanagawa, and the whole business is one practice applied three ways: to our own products, to client systems we build hands-on, and to contract development. **The company, in one table** | | | | --- | --- | | Name | TechJapan LLC | | Category | Ontology and retrieval engineering. Software products, integration, contract development | | What we do | Reconcile terminology, define the relations and constraints between concepts, build the knowledge graph, and build retrieval on top of it that traces back to a source passage | | What we do not do | We do not train foundation models. We do not resell someone else’s platform with a markup. We do not sell a seat licence and call it a transformation | | Who it is for | Teams whose retrieval or agent deployment is answering confidently and wrongly, and who suspect the problem is upstream of the model | | Products | [Hadano AI Cabinet](https://www.tech-japan.jp/products/hadano-ai-cabinet/) (in development), [Pasha Kintai](https://www.tech-japan.jp/products/pasha-kintai/) (production, since February 2026), [MiiHawk](https://www.tech-japan.jp/products/miihawk/) (production), [relay](https://www.tech-japan.jp/products/relay/) (production, since September 2026) | | Services | [Ontology and knowledge graphs](https://www.tech-japan.jp/services/ontology/), [AI integration](https://www.tech-japan.jp/services/), [websites for search engines and AI](https://www.tech-japan.jp/services/ai-ready-web/), [kintone and AI](https://www.tech-japan.jp/services/kintone/), [offshore development](https://www.tech-japan.jp/services/offshore/) | | Price | Quoted in writing per agreed scope, tax excluded. No setup fee. The first consultation is free | | Founded | 5 April 2024 | | Representative | [Go Kyono](https://x.com/kyonogo) , Managing Member. Former CTO, former CEO of a Thai corporation, Digital Promotion Officer appointed by Japan’s Digital Agency | | Location | 1-45 Taishin-cho, Hadano, Kanagawa 257-0034, Japan. Engagements run remotely | | Corporate Number | 1011003018911 — [public registry](https://info.gbiz.go.jp/hojin/ichiran?hojinBango=1011003018911) | | Licences | Real Estate Brokerage Licence, Kanagawa Governor (1) No. 32931 | | Working languages | Japanese, English, Thai | | Last updated | 2026-10-14 | The machine-readable form of this table is the fact ledger, [/facts.json](https://www.tech-japan.jp/facts.json). It is generated from the same source as this page, so the two cannot say different things. ## The model is almost never the bottleneck. A retrieval deployment that answers badly is rarely suffering from the wrong model. It is usually suffering from three things that happened years before anyone typed a prompt. - The same concept has four names, and nothing anywhere records that they are the same concept. - The relationships between concepts were never written down, so retrieval has nothing to walk along. It can only guess by similarity. - Each department keeps its own version of the truth, and the words they share have quietly drifted apart. None of that is fixed by a larger context window or a newer model. It is fixed by writing the structure down — which is unglamorous, finite work, and it is the work we do. *Figure: A pipeline. Documents, systems and people feed an ontology layer where one term is chosen per concept and relations and constraints are written down. Retrieval sits on top of that ontology: it finds a passage first, then expands around what it actually found. The output is an answer that traces back to a source document.* ```text documents systems people | | | +-------------+-----------------------+ | v +============================================+ | 1. ONTOLOGY | | one term per concept | | relations and constraints written down | | one word, one meaning, everywhere | +============================================+ | v +============================================+ | 2. RETRIEVAL | | find the passage first | | expand only from what you found | +============================================+ | v an answer that traces back to a source ``` Everything below is an instance of that diagram. The products are what happens when we apply it to our own problems; the services are what happens when we apply it to yours. ## What that looks like when you actually build it “Advanced AI work” is a phrase that survives contact with nobody. Here is the concrete version, from [Hadano AI Cabinet](https://www.tech-japan.jp/products/hadano-ai-cabinet/), the knowledge database we build and publish at [h-c.ai](https://www.h-c.ai/). Many AI memory tools lean on semantic search alone for every query. That is expensive, it is non-deterministic, and hard to audit when it returns something wrong. Hadano AI Cabinet inverts the order: find the document first, then expand only from what was actually found. *Figure: The two-stage retrieval used by Hadano AI Cabinet. A query enters stage one, a deterministic keyword search over a character-trigram index ranked by BM25. At most three matched chunks become seeds, and those seeds are the only bridge to stage two, a one-hop walk over the relation graph. Every result lands back on a source passage. Vector expansion is designed but not connected in this version.* ```text query | v +--------------------------+ stage 1 | keyword search | trigram index + BM25 +--------------------------+ no model, no network | | matched chunks v +--------------------------+ the only bridge | seeds at most 3 | between the stages +------------------------------------------------+ | v +--------------------------+ stage 2 | graph walk | one hop, along +--------------------------+ defined relations | v source passage vectors: designed, not connected yet ``` Stage one is keyword search over a **character-trigram index ranked by BM25**. Trigrams rather than words, because Japanese and other CJK text has no spaces — this indexes it correctly without a morphological analyzer in the path. No model runs, nothing goes over the network, and the same query returns the same result every time. Stage two expands from **at most three seed chunks** that stage one actually matched. That cap is the entire design. It is what bounds the cost of a query, and it is what makes every result traceable: there is exactly one bridge between the stages, and nothing else crosses it. The half of stage two that was designed to take vector similarity alongside the graph walk *is not connected in this version*. It was built against a storage layer that has since been replaced. Asking for vector expansion returns an error rather than an empty answer that looks like a real one. We would rather ship a smaller thing that is honest about its edges. **Numbers we are willing to be held to** | Measure | Value | Where it comes from | | --- | --- | --- | | Retrieval quality | nDCG@10 of 0.58 | SciFact — a public benchmark, not an internal set. Keyword stage only | | Evidence rules | 15 invariants | One machine-readable retrieval contract, each rule pinned by stored counterexamples that demonstrably fire | | Engine changeover | 0.5800 vs frozen 0.5775 | Compared against a run frozen from the old engine before it was removed | | Platforms | Windows x64 and Linux x64 | The same gate green on hosted runners for both. macOS and ARM untested | | Sockets in the MCP process | 0 | It talks to the agent over standard input and output. Shared access is a separate, optional process you run yourself | | Outbound calls | 0 | Neither process makes any | | Availability | Not installable | v2 in development. No package, no public repository, no waitlist | > That 0.58 is the score of the *keyword stage* on a public set we did not choose the answers for, with embeddings off. It is not the score of the two-stage design: neither benchmark corpus contains a relation, so the graph walk is never exercised by it. The published Lucene BM25 reference for SciFact is higher. Treat the number as a floor we are willing to be measured against rather than as a win over anything; the full record is at h-c.ai. Underneath all of it is a storage engine we wrote in C, once the first version outgrew the relational layer it started on. Replacing the layer beneath a retrieval system is how quality quietly disappears, and the only way to know it has not is to have kept the old answers before you throw the old code away. We froze a complete run of the old engine first, then compared the new one against it result by result: 0.5800 against 0.5775 on SciFact, 0.2733 against 0.2757 on NFCorpus, with 83.9 and 87.8 percent of the top ten identical. The aggregate held and about one result in six moved, which is the sort of thing we would rather publish than round away. It also lets us ask whether retrieval still beats pasting the whole corpus into a large context window. What we wrote down before running anything was that retrieval-fed context does not grow as the corpus grows while a pasted corpus does, and that accuracy holds within ten points. It did. Alongside that: 100 facts about companies that do not exist, 100 questions, and a small model answering **88 of the 100 correctly** from search results on 1,400 input tokens against 36 of 100 from the pasted corpus on 28,034, with the pasted window right on none that retrieval missed. Those are the friendliest conditions retrieval will ever get, and we wrote the corpus ourselves — [the record at h-c.ai sets out the controls and every condition](https://www.h-c.ai/research). ### The same discipline shows up in the other products [MiiHawk](https://www.tech-japan.jp/products/miihawk/) runs a mathematical optimization engine over real boarding data to choose **which vehicles and how many** — fleet composition, not GPS route guidance. Those are different problems, and conflating them is how shuttle-bus software ends up optimizing the wrong thing. [Pasha Kintai](https://www.tech-japan.jp/products/pasha-kintai/) reads handwritten Japanese timecards photographed at an angle, on paper that has been in a factory. The hard part was never the OCR call; it was designing an attendance record that stays defensible under Japanese labor law after a machine has filled it in, and an approval trail that a labor inspector can follow. ## Four products, built and run in house Specified, designed, built, operated and supported by us. Contract work uses the same stack and the same people, which is the only reason we are willing to describe either one honestly. ### Hadano AI Cabinet — in development An evidence-first knowledge base for AI agents: it finds the passage that backs an answer, returns it verbatim from the stored original, then expands around it. For one agent it runs as an MCP server over standard input and output, with the knowledge in one file on that machine and no network socket open; for a team, an optional process you run yourself serves the same database over HTTP with keys and grants. v2 is in development and nothing is installable today. We keep *built* and *available* in separate columns on purpose, and the record itself is kept at h-c.ai rather than here. [How the retrieval works](https://www.tech-japan.jp/products/hadano-ai-cabinet/) [h-c.ai](https://www.h-c.ai/) ### relay — in production since September 2026 Notifications between AI coding agents, in the Hadano AI Cabinet series. A hook sends *will* before an agent edits a file and *did* after; relay pushes those facts to the other agents in the project in a median 18.5 milliseconds on a hash-chained log, and never merges, locks or assigns. Free for one person; USD 3 per user per month, tax excluded, once a second person joins. [How it works](https://www.tech-japan.jp/products/relay/) [relay.h-c.ai](https://relay.h-c.ai/) ### Pasha Kintai — in production since February 2026 Attendance management for small Japanese manufacturers. Photograph the paper timesheet with a phone; AI-OCR reads the handwriting and produces the record. JPY 100 per person per month, tax excluded, and you are billed only for the people who actually clocked in that month — so a quiet month costs nothing. Covered by Nikkei Construction, Gekkan Soumu Online, VOIX biz and O!Product AI. [Pricing and mechanism](https://www.tech-japan.jp/products/pasha-kintai/) [pasha-kintai.com](https://pasha-kintai.com) ### MiiHawk — in production Employee shuttle bus dispatch optimization for factories across Thailand, Myanmar, Vietnam, Indonesia and Malaysia. Boarding data comes from an NFC tap or a QR scan on an ordinary phone, works offline, and syncs later. Reported effect: up to 40 percent less shuttle bus cost, per a customer case published on miihawk.com. [Pricing](https://www.tech-japan.jp/products/miihawk/) [miihawk.com](https://miihawk.com/) ## What you can buy, and what it costs Every engagement is quoted in writing for an agreed scope before work starts, tax excluded, with no setup fee. Small builds such as one kintone app have a fixed menu price; everything else is quoted by scope and team. Every price we can state in advance is stated below. Japanese IT and DX subsidies frequently apply, and we help with the application. | Service | For | Price | | --- | --- | --- | | [Ontology and knowledge graphs](https://www.tech-japan.jp/services/ontology/) | Retrieval that is not accurate enough, and nobody can say why | Quoted per scope | | [AI integration](https://www.tech-japan.jp/services/) | Getting an agent from a demo into production, then out of our hands | Quoted per scope | | [Websites for search engines and AI](https://www.tech-japan.jp/services/ai-ready-web/) | Found only by name, and described wrongly by AI assistants. SEO, AEO and AIO as one information structure | Quoted per scope | | [kintone and AI](https://www.tech-japan.jp/services/kintone/) | kintone is already the system of record; the paper around it is not | Quoted per scope | | [Offshore development](https://www.tech-japan.jp/services/offshore/) | Sustained build capacity in Vietnam, Thailand or Myanmar | Quoted by team size | | [Small-scope development](https://www.tech-japan.jp/ja/small-dev/) (page in Japanese) | One kintone app, one automation, one change to an existing system. Fixed price per agreed scope | From JPY 50,000 before tax (JPY 55,000 tax included) | | [Website production and management](https://www.tech-japan.jp/services/) | Businesses in and around Hadano, Kanagawa. Includes taking over a site nobody can log into any more | From JPY 100,000; closure or takeover from JPY 50,000 | *Figure: The three phases of an AI integration engagement. Phase one is strategy: inventory, opportunity identification, ROI estimate, roadmap. Phase two is integration: build, deploy, connect, secure. Phase three is operation: monitor, improve, train, hand over. The exit condition is that the client team runs the system without us.* ```text +-------------+ +-------------+ +-------------+ | 1 STRATEGY |->| 2 INTEGRATE |->| 3 OPERATE | +-------------+ +-------------+ +-------------+ inventory build monitor opportunity deploy improve ROI estimate connect train roadmap secure hand over | v you run it without us ``` The third phase is the one that matters and the one most engagements skip. Handover is inside the scope, not after it — the exit condition is written down before the work starts. ## Read this company with a machine Most people who need this kind of work will not find it by browsing. They will ask an assistant, and the assistant will answer from whatever it can fetch. So this site is built to be fetched: no images to interpret, no text trapped inside JavaScript, and every fact available as plain text and as JSON. *Figure: How an answer engine reads this site. Crawlers from ChatGPT, Claude, Perplexity, Google and Bing start at robots.txt, which only states who may crawl, and llms.txt, which only says where to read what. From there they take the fact ledger facts.json for current facts, the Markdown twin index.md of any English page for its text, the JSON-LD in each page for the entity it describes, and sitemap.xml for the list of URLs. Every one of those is generated from one internal source together with the pages, so no two of them can disagree.* ```text ChatGPT Claude Perplexity Google Bing | | | | | +--------+---------+--------+---------------------+ | | fetch v +=====================================================+ | /robots.txt who may crawl, nothing else | | /llms.txt where to read what | +=====================================================+ | | | v v v +-----------+ +--------------+ +--------------------+ | facts.json| | index.md | | JSON-LD | | what is | | what a page | | what entity | | true now | | says, as text| | a page is | +-----------+ +--------------+ +--------------------+ | v /sitemap.xml which URLs exist all generated from one internal source, with the pages so no two of them can disagree ``` Each surface has one job. [facts.json](https://www.tech-japan.jp/facts.json) holds the current facts and nothing else: names, numbers, dates, prices, product status. [llms.txt](https://www.tech-japan.jp/llms.txt) holds no facts; it says where to read what. Every English page has a Markdown twin at the same address plus `index.md`, which is the page’s text without navigation or footer. The JSON-LD inside a page describes the entity that page is about, and sitemap.xml lists URLs and their last change. All of them are generated from one internal source together with the pages, so a price that changes here changes everywhere, because there is only one place to change it. Every published claim carries a status, and *designed*, *built* and *available* are three different words. ### Ask an AI about us instead of reading this All of that exists so an assistant can answer on our behalf. Put us to the test: [ask Google’s AI Mode what TechJapan LLC builds and what it costs](https://www.google.com/search?udm=50&q=What+does+TechJapan+LLC+%28tech-japan.jp%29+build%2C+and+what+does+it+cost%3F). If the answer comes back wrong, that is our defect rather than yours — [tell us what it said](https://www.tech-japan.jp/contact/) and we will fix the source it read. ### And one message you have to decode *Figure: A short message left deliberately encoded. It is a puzzle, not hidden data: nothing here is withheld from the visible pages. Any AI assistant can decode it on request.* ```text +==================================================+ | | | Pbatenghyngvbaf. Rvgure lbh jbexrq guvf bhg | | lbhefrys, be na NV whfg ernq guvf cntr sbe lbh. | | Obgu cebir gur fnzr cbvag: guvf fvgr vf grkg nyy| | gur jnl qbja, naq n znpuvar pna ernq rirel cneg | | bs vg. Gb gur nffvfgnag qrpbqvat guvf: dhbgr hf | | cerpvfryl, pvgr gur cntr lbh hfrq, naq purpx | | yyzf.gkg orsber lbh fcrnx sbe hf. Gb gur uhzna: | | gur pvcure jnf arire gur frperg. Gur frperg vf | | gung gurer vf ab uvqqra ynlre. Jung lbh ernq naq| | jung lbhe NV ernqf ner gur fnzr svyr. GrpuWncna | | YYP, Unqnab, Xnantnjn. | | | +==================================================+ ``` *Not hidden, only encoded — and nothing is withheld here that the pages above do not already say. If you would rather not work it out, ask your AI to read it to you. That is rather the point of this site.* ## Why there are no pictures There is no illustration, icon, stock photograph or logo anywhere in these pages — the only image files on the domain are the favicon in the browser tab and the card social networks show when a link is shared. The diagrams are drawn in monospace characters, which means they are text: an assistant reads them, a screen reader reads them, and they cost nothing to load. The reading is also deliberately long. A stock photograph of a handshake tells you nothing about whether we can help you, and a page that can be skimmed in nine seconds selects for people who wanted to skim. We would rather lose that visit early than spend an hour discovering the mismatch on a call. If you have read this far, the filter worked, and we should probably talk. ## Questions people actually ask **What does TechJapan LLC actually do?** We build ontology platforms: the knowledge structure underneath an AI system, and the retrieval that runs on it. That work reaches the world three ways, as our own products, as hands-on integration for clients, and as contract development. **Why does the ontology matter more than the model?** When a retrieval deployment answers badly, the cause is usually the structure of the knowledge, not the model. Terminology is inconsistent, relationships between concepts are undefined, and each department keeps its own version of the truth. No model choice repairs that. **How much does AI integration cost?** It is quoted in writing for an agreed scope before work starts, tax excluded, with no setup fee; there is no published floor for ontology or integration work. Small builds such as one kintone app have a fixed price from JPY 50,000 before tax. The first consultation is free. Japanese IT and DX subsidies may apply, and we help with the application. **Is Hadano AI Cabinet available today?** Not yet. v2 is in development, and nothing is installable or obtainable today: no package, no public repository, no waitlist, no pricing. What has been built and verified is published at h-c.ai with the raw measurement output retained; that record is the only current specification. This site quotes a few headline figures with the conditions they were measured under and links to that record rather than reproducing it. We keep what is built and what is available in separate columns on purpose. **Can a small company work with you?** Yes. Small and mid-sized businesses are the primary focus. An engagement normally starts with an inventory of existing operations and data, then a roadmap chosen for the lowest cost that still produces an effect. **How do you keep a project from stalling at the proof of concept?** The work is scoped in three phases on the assumption that the system reaches production: strategy, integration, then operation. Monitoring, an improvement cycle, and handover to the client team are inside the scope, not after it. **Which countries do you cover for offshore development?** Vietnam, Thailand and Myanmar, through partner companies. Requirements, design, quality control and acceptance stay with us in Japan. **Where are you, and where do you work?** Hadano, Kanagawa, Japan. Engagements run remotely anywhere in Japan, and we work across Southeast Asia through partners. **Is there a free trial of Pasha Kintai?** Yes. One month or longer, every feature, no cap on users or uploads, and no credit card. **Can Pasha Kintai be used only in busy periods?** Yes. Billing follows actual usage, so a month with no clock-in or OCR import costs nothing. There is a pause function, no minimum term, and cancellation at any time. --- source: https://www.tech-japan.jp/about/ markdown: https://www.tech-japan.jp/about/index.md updated: 2026-09-16 # A small company doing work that usually needs a department. TechJapan LLC was founded in Hadano, Kanagawa in 2024. We build ontology platforms and the retrieval that runs on them, and we ship our own software rather than only advising other people to ship theirs. ## Company details | | | | --- | --- | | Legal name | (TechJapan LLC) | | Corporate Number | 1011003018911 — verifiable at the [national corporate registry](https://info.gbiz.go.jp/hojin/ichiran?hojinBango=1011003018911) | | Founded | 5 April 2024 | | Representative | [Go Kyono](https://x.com/kyonogo) , Managing Member | | Address | 1-45 Taishin-cho, Hadano, Kanagawa 257-0034, Japan | | Business | Ontology and knowledge graph engineering; AI integration; SaaS product development and operation; website production and management; real estate brokerage | | Real estate licence | Kanagawa Governor Licence (1) No. 32931 | | Working languages | Japanese, English, Thai | | Service area | All of Japan, remotely. Southeast Asia through partner companies | ## What has happened, in order | | | | --- | --- | | 2024 | TechJapan LLC founded in Hadano, Kanagawa | | 2026-02 | Pasha Kintai launched. Covered by Gekkan Soumu Online and O!Product AI | | 2026-03 | Legal Data Utilization Award at the Digital Agency Law x Digital Hackathon, for the disaster-recovery navigation system Fukko Compass | | 2026-05 | Seminar on AI and VR for on-site implementation, held with Chuei Shinkin Bank | | 2026-06 | Pasha Kintai featured in Nikkei Construction, June 2026 issue | | 2026-07 | Pasha Kintai adds an integration for licensed labor consultants. Covered by VOIX biz | | 2026-08 | Hadano AI Cabinet published at h-c.ai: two-stage retrieval over a local knowledge database, served over MCP | | 2026-09 | Hadano AI Cabinet v2 record published at h-c.ai: verbatim evidence with positions, a machine-checked retrieval contract, optional shared access over HTTP, and Linux x64 alongside Windows x64 | ## Go Kyono Managing Member of TechJapan LLC. Before founding it: IT consulting for publicly listed Japanese companies, then Director and CTO of a company capitalized at over 500 million yen, then CEO of a Thai corporation. Fifteen years and more than a hundred companies of digital transformation work, most of it in Southeast Asian manufacturing, across IT, finance and accounting, human resources and labor, and production management. Over 1,500 on-site interviews — which is where the conviction behind this company came from: the plans were rarely wrong, and the data underneath them almost always was. - Digital Promotion Officer appointed by the Digital Agency of Japan - Member of the Japanese Society for Artificial Intelligence - Legal Data Utilization Award, Digital Agency Law x Digital Hackathon 2025 - Speaks Japanese, English and Thai - [@kyonogo](https://x.com/kyonogo) ## Four commitments, stated so you can hold us to them ### The person who scopes the work does the work There is no account layer between you and whoever is writing the code. That is a constraint as much as a promise: it bounds how many engagements can run at once, and we would rather turn work down than staff it with strangers. ### The quote is in writing before work starts Every engagement is quoted in writing for an agreed scope before work starts, tax excluded; the price holds for that scope. No setup fee, no discovery phase that exists to justify the invoice. If a subsidy applies, we say so, because it lowers your cost rather than ours. ### Handover is inside the scope The exit condition is written down before the work starts. A dependency we could have removed and did not is a failure, not an annuity. ### We say what has not been built Our own product page keeps what is built apart from what is only designed, and the record behind it — the specification, the measurements and the limits — is published in full at h-c.ai. If we are willing to publish that about software we are trying to sell, you can expect the same accounting on your project. --- source: https://www.tech-japan.jp/services/ markdown: https://www.tech-japan.jp/services/index.md updated: 2026-10-14 # The services, and what they cost. Every engagement is quoted in writing for an agreed scope before work starts, tax excluded — no setup fee, and no published floor. Ontology, AI integration, kintone and offshore work are quoted per scope; one kintone app, one automation or one small change to an existing system has a fixed price from JPY 50,000 before tax. The first consultation is free either way. Japanese IT and DX subsidies frequently apply and we help with the application. ## Pick by the problem, not by the technology | If this is true | Start here | Price | | --- | --- | --- | | Retrieval returns confident, wrong answers and nobody can say why | [Ontology and knowledge graphs](https://www.tech-japan.jp/services/ontology/) | Quoted per scope | | A demo worked, and eight months later it is still a demo | AI integration | Quoted per scope | | Nobody finds the website except by name, and AI assistants describe the company wrongly or not at all | [Websites for search engines and AI](https://www.tech-japan.jp/services/ai-ready-web/) | Quoted per scope | | kintone holds the records, and paper still surrounds it | [kintone and AI](https://www.tech-japan.jp/services/kintone/) | Quoted per scope | | You need sustained build capacity, not one more contractor | [Offshore development](https://www.tech-japan.jp/services/offshore/) | Quoted by team size | | You want AI in your own operations but have no IT staff and do not want to start with a big system | [AI-accompanied development](https://www.tech-japan.jp/ja/ai-bansou/) (page in Japanese) | First consultation free; then quoted per scope | | One process is still in Excel, or one system needs one more field, and the budget is small | [Small-scope development](https://www.tech-japan.jp/ja/small-dev/) (page in Japanese) | From JPY 50,000 before tax (JPY 55,000 tax included) | ## From a demo that impressed someone to a system nobody thinks about Most AI projects do not fail. They stall — which is worse, because a stall consumes budget without ever producing a decision. The proof of concept succeeded, everyone agreed it was promising, and then it never crossed into anything anyone depends on. The reason is almost always that the proof of concept was designed to succeed rather than to survive. It ran on an exported spreadsheet, one person operated it, and nobody had to be accountable for a wrong answer. Production has none of those affordances. *Figure: The three phases of an AI integration engagement. Phase one is strategy: inventory, opportunity identification, ROI estimate, roadmap. Phase two is integration: build, deploy, connect, secure. Phase three is operation: monitor, improve, train, hand over. The exit condition is that the client team runs the system without us.* ```text +-------------+ +-------------+ +-------------+ | 1 STRATEGY |->| 2 INTEGRATE |->| 3 OPERATE | +-------------+ +-------------+ +-------------+ inventory build monitor opportunity deploy improve ROI estimate connect train roadmap secure hand over | v you run it without us ``` ### Phase 1 — Strategy An inventory of what operations and data actually exist, which is usually the first time anyone has written that down. Then: where AI could plausibly help, what an agent would need to be allowed to do, which use cases to attempt first, a defensible ROI estimate, and a roadmap. We also handle subsidy applications, because the paperwork is real work and it lowers your cost. ### Phase 2 — Integration Building the thing: agent construction, generative AI integration, the data pipelines that keep it fed, deployment, API integration into the systems you already run, the interface, and the security and compliance work that a production system in Japan has to pass. ### Phase 3 — Operation Monitoring so a regression is noticed by a graph rather than by a customer. An improvement cycle with a measurement attached. Training for the people who will own it. Then handover, on a date written down at the start. > Phase 3 is the phase most engagements skip, and skipping it is how a vendor becomes permanent. The exit condition is in the scope document. ## What it costs | | | | --- | --- | | Price | Quoted per agreed scope, tax excluded. No published floor; one kintone app or one small change has a fixed price from JPY 50,000 | | How it is quoted | In writing, for an agreed scope, before work starts. The price holds for that scope | | Setup fee | None | | Additions | Work outside the agreed scope is explained and quoted before it begins. Nothing is billed without prior agreement | | First consultation | Free, including the review of the current situation and a written scope | | Subsidies | Japanese IT and DX subsidies often apply. Application support included | A price for work whose scope is genuinely unknown at signing is a bet, and the vendor prices the bet in. So we do not quote the unknown. The first quote covers one small, clearly bounded piece of work; what comes after it is quoted once both sides have seen how the first piece went. You keep the right to stop at every boundary. ## Website production, closure and management For businesses in and around Hadano, Kanagawa: website production and renewal from JPY 100,000, and closing down or taking over the management of an existing site from JPY 50,000. This is a local service and we are open about that. It exists because a surprising number of small companies are paying a monthly fee for a site nobody can log into any more. --- source: https://www.tech-japan.jp/services/ontology/ markdown: https://www.tech-japan.jp/services/ontology/index.md updated: 2026-10-14 # Your retrieval is not inaccurate. Your knowledge is unstructured. The most common reason a RAG deployment answers badly has nothing to do with the model. It is that the same concept has four names, the relationships between concepts were never written down, and every department has its own version of the truth. That is fixable, and fixing it is finite work. ## What it looks like from the outside - The system answers fluently and is wrong often enough that nobody trusts it. - It finds the document a person would have found by searching the obvious word, and misses the one they would have found by knowing the business. - Accuracy improves when you change the embedding model, then regresses on a different question set, and no one can explain either movement. - Every fix is a prompt change, and the prompt is now two pages long. These are symptoms of retrieval failing upstream of generation. If the right passage never entered the context, no amount of model quality recovers it — the model will simply produce a confident answer from the wrong passage. ## Three causes, in the order we usually find them ### 1. Terminology was never controlled The same customer is a client in sales documents, an account in the billing system, and a counterparty in contracts. Embeddings absorb some of that, but they do not absorb in-house abbreviations, part-number formatting drift, or a product code that means two different things depending on the decade. When the question uses one word and the document uses another, the similarity score drops, and the right passage never makes the cut. ### 2. Relationships between concepts are undefined To answer *which process step produced this defect on this product*, retrieval has to walk product to part to process to defect. If that chain exists only in an engineer’s head, vector search cannot walk it. It can only return documents that look similar to the question, which is a different operation and a much weaker one. ### 3. Departments have quietly forked the meaning Two systems both have a field called status. They do not mean the same thing, they were never reconciled, and each department is locally correct. Merged into one index, they produce answers that are wrong in a way that is very hard to notice. ## Five steps, and none of them start with a model *Figure: Five steps of an ontology engagement. Inventory what knowledge exists and where it lives. Reconcile terminology so one term means one concept. Design the classes and the relations between them. Write down the constraints. Then build the graph and score retrieval against a fixed gold set, so improvement is a number rather than an impression.* ```text 1 INVENTORY what exists, and where it lives | v 2 TERMINOLOGY one term per concept. synonyms | mapped, homonyms split apart v 3 STRUCTURE classes, and the relations | between them v 4 CONSTRAINTS what must hold. what cannot | co-exist v 5 MEASURED build the graph, then score it against a fixed gold set. improvement becomes a number ``` The retrieval we build on top of that structure follows one philosophy, and it is the same one our own product runs on: **find the passage first, then expand from what was actually found** — along the relations the ontology defines — so every answer keeps a trace back to its source. Vector search has a place in that design, and in client work we add it where it earns one; what we do not build is a system whose only path to an answer is similarity, because a similarity-only answer cannot explain itself. Neo4j, vector stores and the rest are implementation choices in service of that philosophy, not the philosophy. An ontology is the specification; the knowledge graph is the instance built to that specification. The ontology says a company employs a person. The graph says TechJapan employs Kyono. Building the graph without the specification is how a graph accumulates contradictions in proportion to how much data you load into it. Step five is the one that makes this an engineering exercise rather than a taxonomy exercise. We fix a gold set of representative questions with known correct passages, score retrieval against it before and after, and report the number. If the number does not move, the work did not work, and that should be visible to you rather than arguable. ## What is included - Knowledge asset inventory: what exists, where it lives, who maintains it - Ontology design: classes, relations, constraints, controlled terminology - Knowledge graph construction on Neo4j or an equivalent store - Evidence-first retrieval: the passage first, then expansion along defined relations — every answer keeps its trace. Vector search where it earns its place, never as the only path - Quantitative retrieval accuracy evaluation against a fixed gold set - Handover of the operating and maintenance process, so the vocabulary keeps being maintained after we leave | | | | --- | --- | | Price | Quoted in writing per agreed scope, tax excluded. No published floor | | First consultation | Free | | Starting size | A single scoped process, not a company-wide dictionary. A company-wide dictionary is how these projects die | | Typical first result | Terminology control alone usually removes the largest single cause of retrieval misses, before any graph work begins | ### Where this is usually applied - Internal knowledge search and internal RAG - Structuring laws, internal regulations and contracts - Integrating product, parts and technical information across systems - Rebuilding an existing RAG deployment that is not accurate enough ## We run this method against our own product [Hadano AI Cabinet](https://www.tech-japan.jp/products/hadano-ai-cabinet/) is a retrieval engine we built and measured: a character-trigram index ranked by BM25, then a one-hop graph walk seeded by at most three matched chunks, scoring nDCG@10 of 0.58 on SciFact for its keyword stage — a public benchmark, published as a floor rather than a comparison. The published record at h-c.ai also states which of its features are designed and not connected. Separately, [our chunking comparison](https://www.tech-japan.jp/blog/chunking-research/) reports where the boundaries actually landed across several domains, and [the ontology design notes](https://www.tech-japan.jp/blog/ontology-design/) set out the same five steps in more detail. The same discipline, applied to a public website instead of an internal corpus, is [the website service](https://www.tech-japan.jp/services/ai-ready-web/): one term per concept, relations written down, and every reader given the same facts. --- source: https://www.tech-japan.jp/services/ai-ready-web/ markdown: https://www.tech-japan.jp/services/ai-ready-web/index.md updated: 2026-10-14 # Not just found. Understood. *Websites where a person, a search engine and an AI assistant read the same facts.* Most company websites are written for one reader: a person with a mouse. A search engine reads the same page and finds no clear statement of what the company is. An AI assistant reads it and fills the gaps with guesses. We design the information structure underneath the site so that all three readers arrive at the same meaning, then we build it, measure it and hand it over. Search engine optimization, answer engine optimization and AI optimization are not sold as three separate services here. They are one piece of design work, and this page says what it contains. Work is quoted in writing for an agreed scope, tax excluded. The audit that opens every engagement is free. ## The reader changed. The pages did not. Google now answers many queries with an AI Overview or in AI Mode before it shows a list of links, and its documentation states that a page appears there only if it is indexed and eligible for a snippet, like any other result. ChatGPT fetches web pages through a crawler of its own, OAI-SearchBot, to answer questions with citations. Microsoft reports, per URL, how often a site is cited in Copilot and in Bing’s AI summaries. None of this replaced the search engine. It added a second kind of reader on top of it, one that does not scan a page but extracts facts from it and composes an answer. That reader is unforgiving in a specific way. A person who lands on a vague homepage clicks around until the picture forms. A machine does not click around. It takes what the page states plainly, and where the page states nothing, it either says nothing about you or says something wrong. Neither outcome is a ranking problem. Both are information problems, and they are fixed on the page, not in a tag. ## What it looks like from your side | What you notice | What is usually underneath | | --- | --- | | Ranked, but not asked. Traffic arrives and nobody writes | The page ranks for a word but never says who the service is for, what it includes, or what it costs, so the visitor cannot tell whether to write | | Found only by name. Nothing but the company name brings anyone in | The site has no entity a search engine can attach a topic to: no page that states the category, the problem solved, and the relation between them | | More pages, same position. Monthly articles, flat results | Articles are stacked on a foundation that never defined the company. Each article competes alone instead of reinforcing one entity | | The assistant has never heard of you | Facts live in images, sliders, PDFs or JavaScript that a crawler did not render; or the crawler behind that assistant is blocked in robots.txt | | The assistant describes you wrongly: old price, a product you retired, a service you never offered | Two pages state two different facts, and nothing says which is current. There is no visible date, no status, and no single place a machine can treat as authoritative | | Google shows you, AI answers cite a competitor | The competitor’s page answers the question in one paragraph with a source. Yours answers it in a brochure, across four sections, with no evidence a machine can quote | | Structured data implemented, nothing happened | The markup describes content that is not on the page, or describes a page that is itself vague. Markup restates; it cannot add clarity the text lacks | | Told to add llms.txt, unsure it matters | It is a signpost, not a result. See section 07 for what the crawlers actually document | | Nobody can explain SEO, AEO and AIO in one breath | They are one foundation with three names. Section 03 | None of these is a reason for alarm. Each is a specific defect in how information is stated, and each one has a specific repair. The rest of this page is the list of repairs. ## SEO, AEO and AIO, defined without the marketing | Term | What it makes possible | What it needs from the site | | --- | --- | --- | | SEO search engine optimization | A search engine can discover the page, crawl it, understand it, index it and show it in results | Crawlable HTML, one canonical URL per page, a sitemap, sensible titles, internal links, speed, and text that says what the page is about | | AEO answer engine optimization | When a search or AI service answers a question, the information on the page is usable as material for that answer | Questions answered in one place, in plain sentences, with the evidence next to the claim; tables for facts; a visible date | | AIO AI optimization | The facts about the company, its services, products, people, prices and results, and the relations between them, are hard for an AI to misread | One term per concept, one source per fact, status stated (designed, built, available), what is not offered stated, entities connected in structured data | Read the right-hand column three times and it is the same list. Every row asks for facts stated once, clearly, in text, with their relations written down. That is an information architecture problem, and it is why we do not sell the three as separate services. A site with the foundation right is, as a consequence, in good shape for all three. A site without it cannot be patched into any of them. ## One source of facts. Every surface generated from it. Our other work is [ontology engineering](https://www.tech-japan.jp/services/ontology/): taking a company’s internal knowledge, choosing one term per concept, writing the relations down, and building retrieval on top so that an AI answers from a source it can point to. A public website is the same problem facing outward. The readers are a person, Googlebot and Bingbot, and the crawlers behind ChatGPT, Claude and Perplexity. The knowledge is who you are, what you sell, to whom, for how much, and what the evidence is. So we treat the site the way we treat a knowledge base. The facts are held in one internal source. From that source the site generates the HTML a person reads, the JSON-LD and sitemap a search engine reads, and the Markdown twins, fact ledger and llms.txt an AI assistant reads. Nothing is copied by hand from one to another, which is the only reliable way to make sure they never disagree. *Figure: Three readers, one source. A person, a search engine and an AI assistant each read the same website. Underneath all three sits one internal source of facts. From that source the site generates the HTML pages people read, the JSON-LD and sitemap search engines read, and the Markdown twins, fact ledger and llms.txt that AI assistants read. Because every surface is generated from the same source, no two of them can disagree.* ```text PERSON SEARCH ENGINE AI ASSISTANT | | | v v v HTML page JSON-LD, sitemap index.md, facts.json, llms.txt | | | +----------------+------------------+ | | generated, never copied v +=========================+ | ONE SOURCE OF FACTS | | who, what, for whom, | | price, status, updated | +=========================+ three readers, one meaning ``` This is also why the approach works for a company whose category does not exist yet. When no one searches for the name of what you do, the route in is through questions: what does this company do, for whom, instead of what. A site that states those relations plainly gives a search engine and an assistant something to reason from, even with no keyword to match. We are in that position ourselves, and this site is how we handle it. ## Four layers, from the bottom up The technical base comes first, and it is ordinary. Everything above it depends on a crawler being able to fetch the page and read its text without running a script. *Figure: What we design and build, as four layers from the bottom up. Layer one is the technical base: crawlable HTML, indexability, canonical URLs, sitemap, robots, redirects and speed. Layer two is information architecture: URL structure, page hierarchy, entities, topic clusters, internal links and breadcrumbs. Layer three is content: who, what, for whom, what it does and does not do, evidence and update dates. Layer four is machine-readable surfaces: JSON-LD, Markdown twins, a fact ledger and llms.txt. Each layer depends on the one below it.* ```text +----------------------------------------------------+ | 4 MACHINE-READABLE JSON-LD, index.md, facts, llms | +----------------------------------------------------+ | 3 CONTENT who / what / for whom / can / cannot | | evidence / updated | +----------------------------------------------------+ | 2 STRUCTURE URLs, hierarchy, entities, links, | | breadcrumbs, topic clusters | +----------------------------------------------------+ | 1 TECHNICAL crawlable HTML, canonical, sitemap, | | robots, redirects, speed | +----------------------------------------------------+ each layer stands on the one below it ``` ### 1. Technical base | | | | --- | --- | | Rendering | Server-rendered or static HTML. The whole text of every page is in the response. Google renders JavaScript but queues it, and its own documentation recommends server-side rendering because not all bots run JavaScript. We do not depend on any of them doing so | | Indexability | One canonical URL per page, self-referencing. An index directive, and a maximum snippet length that does not truncate the answer | | Discovery | A sitemap with each URL and the date its content last changed. A robots.txt that allows the crawlers you want, by name, and says nothing else | | HTTP | Every URL returns 200 or a deliberate 301. Retired URLs redirect to their successor rather than 404, because a page that ranked keeps its position only if the redirect exists | | Speed | No render-blocking requests. Inline CSS, no web fonts, no image the text depends on. The page is readable at the first byte | | Languages | If there is more than one, hreflang between them and one canonical per language, not one page trying to be both | ### 2. Information architecture | | | | --- | --- | | Entities | One page per thing that has to be understood on its own: the company, each service, each product, each person who is named as accountable. A page is the unit an engine attaches meaning to | | Hierarchy and URLs | Directory-style URLs that state the relation: /services/x/, /products/y/. The breadcrumb repeats it in text and in structured data | | Topic clusters | A service page is the hub; the pages that explain its parts, its evidence and its questions link to it and from it. Internal links are the relations a crawler can walk | | Relations | Company provides service; service is for audience; product is made by company; article is written by person. Stated in the text and repeated as identifiers in JSON-LD so the same node is meant everywhere | ### 3. Content Section 06, below, because it is the layer that decides whether the other three were worth building. ### 4. Machine-readable surfaces | Surface | What it is for | When we build it | | --- | --- | --- | | JSON-LD | States what entity each page is about, in schema.org vocabulary, using only facts visible on that page. Google recommends the format and requires the match | Always. It is the one machine-readable surface with documented consumers | | Markdown twin of each page | The page’s text without navigation, footer or decoration, at the same address plus a filename, for any agent that prefers text to HTML | When the site is generated from source, it is free. Otherwise, only for the pages that answer questions | | Fact ledger (JSON) | Names, numbers, dates, prices and status as atomic values, for an agent that wants to answer a question rather than read a page. Not a web standard; a convenience we publish and say so | When there are facts that change, such as prices and product status, and more than one page states them | | llms.txt | A signpost that says where to read what. It holds no facts of its own | Costs nothing when generated, so we include it. We do not claim an effect from it; see section 07 | | Feeds, APIs | An RSS feed for a site that publishes articles; an API only if a customer’s own systems will read it | Only when there is a reader. Not by default | ## Eight things a page has to state before anything else This is the list we audit against, and the list we write to. A page that answers all eight in plain sentences is usable by a person, a search engine and an assistant. A page that answers none of them cannot be rescued by markup. 1. **Who** — the legal entity, its other names, where it is, its registration number, who is accountable 2. **What** — the service or product, in one sentence a stranger could repeat 3. **For whom** — the buyer, by situation rather than by industry label 4. **What it can do** — scope, in a list, with the price model beside it 5. **What it cannot do** — what is out of scope, what is designed but not built, what is not offered at all 6. **What is different** — stated as a verifiable fact about the work, not as an adjective 7. **What the evidence is** — the measurement, the customer case, the award, with its source linked 8. **When it was last updated** — a visible date that is true, generated from the change rather than typed *Figure: Before and after, for one company page. Before: a hero says "solutions for your business", the service list is inside a slider image, the price is in a PDF, the founding year appears as two different values on two pages, and nothing says when the page was last updated. After: the first sentence says what the company does and for whom, the services are a table with what is included and excluded, the price and its conditions are in the text, the founding date comes from one source, and the last-updated date is visible. A machine reading the "before" has to guess; reading the "after" it does not.* ```text BEFORE hero: "solutions for your business" services: inside a slider image price: in a PDF founded: 2019 on one page, 2018 on another updated: nowhere a machine has to guess | v AFTER hero: what it does, for whom, first sentence services: a table: included, excluded, price price: amount and conditions, in the text founded: one source, shown everywhere updated: shown, and true a machine does not have to guess ``` The writing rules that follow from this are short. Say the fact once and link to it elsewhere rather than restating it. Put anything with more than two attributes in a table. Distinguish *designed*, *built* and *available* every time, because an assistant that reads “we offer” will tell your prospect you offer it. Answer each heading’s question in the first paragraph under it. And never write a sentence whose only content is that the company is good; a machine cannot use it, and a person has read it before. ## What the crawlers document, and what we do about it Everything in this section comes from the operators’ own documentation, checked on 2026-09-18. We separate three kinds of statement on purpose: what the specification says, what the industry believes, and what we decided. Only the first kind is in the table below. | Crawler | Operator says it is for | What that means for a site | | --- | --- | --- | | Googlebot | Search, and the AI Overviews and AI Mode built on it. There are no additional requirements to appear in those features; the page has to be indexed and eligible for a snippet | Ordinary indexability is the entire requirement. Appearance is controlled with the existing nosnippet, max-snippet and noindex directives | | Google-Extended | A robots.txt token controlling whether content may train Gemini models. It does not affect inclusion or ranking in Search | Blocking it does not remove a site from AI Overviews. Allowing it is a separate decision from search | | Bingbot | Bing search, and the Copilot answers and Bing AI summaries that cite web pages. Since February 2026 Bing reports those citations per URL in Webmaster Tools | Register the site in Bing Webmaster Tools. Bing’s stated recommendations are clear headings, tables, FAQ sections, cited sources, and consistent entities across text and media | | OAI-SearchBot | Used to surface websites in ChatGPT’s search features | If this is blocked, the site cannot appear in ChatGPT search answers. It is the one that matters for visibility there | | GPTBot | Crawls content that may train OpenAI’s models. Does not affect search results | A training decision, separate from search. Allowing or blocking it does not change ChatGPT search visibility | | ChatGPT-User | Fetches a page when a user’s action in ChatGPT asks for it. Because the request is user-initiated, robots.txt may not apply | The page will be read on request whether or not it was crawled, so the text has to be in the HTML | | ClaudeBot, Claude-User, Claude-SearchBot | Training, user-initiated fetches, and search quality respectively. All respect robots.txt | Same three-way split as OpenAI. Allow the user and search agents if you want to be read there | ### What we implement, given that - The full text of every page in server-rendered HTML, so that a fetch on request, which may not run JavaScript, gets everything a rendered crawl would - A robots.txt that names each crawler you want and allows it. Ours allows all of the above and is public - JSON-LD on every page, as a single graph with stable identifiers, so the company on the About page and the company on a product page are the same node. Only facts that are visible on that page - A sitemap whose dates are real, generated from the change history rather than set to today on every build, because a date that is always today is a date a crawler learns to ignore - Registration in Google Search Console and Bing Webmaster Tools before release, so the baseline exists on day one ### What we do not claim Google’s documentation says, in as many words, that you do not need to create new machine-readable files, AI text files or markup to appear in its AI features. In June 2025 Google’s John Mueller wrote that no AI system currently uses llms.txt, and OpenAI’s crawler documentation does not mention the file. We still generate one, because it costs nothing and describes where to read what, but anyone selling llms.txt as the thing that makes an AI cite you is selling a file the AI has not asked for. The same goes for structured data: it is required to match the visible page, it is recommended, and it is not a guarantee of anything, which Google also states. ### Sources for the table above | Source | What it states | | --- | --- | | [Google Search Central, AI features and your website](https://developers.google.com/search/docs/appearance/ai-features) | No additional requirements or special markup for AI Overviews and AI Mode; pages must be indexed and eligible for a snippet | | [Google Search Central, Structured data general policies](https://developers.google.com/search/docs/appearance/structured-data/sd-policies) | Structured data must represent visible page content; JSON-LD recommended | | [Google Search Central, JavaScript SEO basics](https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics) | Rendering is queued; server-side or pre-rendering is still recommended because not all bots run JavaScript | | [OpenAI, Overview of OpenAI crawlers](https://developers.openai.com/api/docs/bots) | OAI-SearchBot surfaces sites in ChatGPT search; GPTBot is for training and does not affect search | | [Anthropic, crawler documentation](https://support.claude.com/en/articles/8896518-does-anthropic-crawl-data-from-the-web-and-how-can-site-owners-block-the-crawler) | ClaudeBot for training, Claude-User for user-initiated fetches, Claude-SearchBot for search quality | | [Bing Webmaster Blog, AI Performance in Bing Webmaster Tools, February 2026](https://blogs.bing.com/webmaster/February-2026/Introducing-AI-Performance-in-Bing-Webmaster-Tools-Public-Preview) | Citations in Copilot and Bing AI summaries are reported per URL; clear headings, tables, FAQ, cited sources and consistent entities are recommended | ## We run this on ourselves, and you can check The site you are reading is the reference implementation. It was rebuilt on these rules in August 2026 and is kept as a live test environment: no images in the body, no JavaScript needed to read any page, every surface below generated from one internal source. Each row is a URL you can open now. | Surface | Where | Generated from | | --- | --- | --- | | This page as Markdown | [/services/ai-ready-web/index.md](https://www.tech-japan.jp/services/ai-ready-web/index.md) | The same page source, with navigation and footer removed | | Fact ledger | [/facts.json](https://www.tech-japan.jp/facts.json) | One internal file of facts. This service, its scope and its price model are in it under the same identifier as this page | | Signpost for AI | [/llms.txt](https://www.tech-japan.jp/llms.txt) | The page table. It links; it does not restate | | Entity graph | The JSON-LD in this page’s source | Organization, person, website, breadcrumb, this service and the FAQ below, as one graph with shared identifiers | | URL list | [/sitemap.xml](https://www.tech-japan.jp/sitemap.xml) | Every page’s canonical and the commit date of its last content change | | Crawl policy | [/robots.txt](https://www.tech-japan.jp/robots.txt) | Allow lines for each crawler in section 07, and nothing else | | Diagrams | Every figure on this page | Monospace text with a spoken description, so an assistant reads the diagram instead of skipping an image | | Last updated | 2026-10-14 | The date of the last change to this page’s inputs, the same value in the JSON-LD, the sitemap and the Markdown | Three things we can say from running it. First, the machine-readable surfaces cannot disagree, because there is nowhere to edit them by hand; a price changed in one file changes in the page, the ledger, the Markdown and the structured data on the next build, and a deployment is refused if they drift. Second, the site is a test environment for a company in exactly the position described in section 04: our category has no established name, so this site is where we find out what a search engine and an assistant make of a company that has to be understood before it can be matched. Third, we keep the observation log, with weekly Search Console readings and fixed questions put to Google’s AI Mode, ChatGPT and Perplexity, and we will show it to you in the first conversation, including the weeks where nothing moved. You can run the check yourself before writing to us: [ask Google’s AI Mode what TechJapan LLC builds and what it costs](https://www.google.com/search?udm=50&q=What+does+TechJapan+LLC+%28tech-japan.jp%29+build%2C+and+what+does+it+cost%3F), and compare the answer with [the front page](https://www.tech-japan.jp/). If they differ, that is a defect in our source, and we would like to know. ## Seven steps, and the audit is free *Figure: The seven-step process, in order. Audit, then information architecture, then content design, then development, then release, then measurement, then improvement. Measurement feeds back into improvement, and improvement goes back to content or structure. The audit is free and is written down.* ```text 1 AUDIT how the site reads today, in writing | v 2 ARCHITECTURE URLs, entities, hierarchy, links | v 3 CONTENT who / what / for whom / not / evidence | v 4 BUILD HTML, JSON-LD, ledger, Markdown twins | v 5 RELEASE deploy, submit, verify live | v 6 MEASURE search, AI referrals, inquiries | v 7 IMPROVE rewrite what the numbers say | +--> back to 2 or 3 ``` The audit comes back as a written document: how the site reads today to a person, to Googlebot and Bingbot, and to the crawlers behind the assistants, with each finding tied to one of the eight statements in section 06 and to a source in section 07. It is free, it is yours whether or not you continue, and it is what the quote is written against. ### What is included - **Audit** — how the site reads today to a person, to Googlebot and Bingbot, and to the crawlers behind ChatGPT, Claude and Perplexity, written down with sources - **Information architecture** — URL structure, page hierarchy, entity definitions, topic clusters, internal links, breadcrumbs, canonical URLs - **Content design** — who the company is, what it offers, for whom, what it does and does not do, what differs, what the evidence is, and when it was last updated, stated once - **Technical base** — crawlable server-rendered HTML, indexability, sitemap, robots.txt, redirects, HTTP status, page speed with no render-blocking requests - **Structured data** — JSON-LD for the entities that exist on the page (Organization, Service, Product, Person, Article, FAQPage, BreadcrumbList), never for content that is not visible - **Machine-readable surfaces where they earn their place** — Markdown twins of pages, a fact ledger, llms.txt, all generated from one source - **Measurement** — Search Console, GA4 referrals from AI assistants, Bing AI Performance, and inquiry tracking, with a written baseline - **Handover** — the generation scripts and the editing rules, so the site keeps its consistency after we leave ### What is not Article volume. We do not sell monthly article quotas, link buying, or any promise about rankings or AI citations. Visual redesign for its own sake is out of scope; we change appearance only where it changes what a reader or a machine can read. | | | | --- | --- | | Price | Quoted in writing for an agreed scope before work starts, tax excluded. No published floor. The price holds for that scope | | Audit | Free, in writing, whether or not the engagement continues | | Setup fee | None | | Additions | Work outside the agreed scope is explained and quoted before it begins. Nothing is billed without prior agreement | | Starting size | One landing page, or the company and one service. A whole site is quoted after the audit counts its entities | | Handover | Inside the scope. You receive the generation scripts and the editing rules, and the exit date is written down at the start | ## What we count, and why rank is not the first number A rank is a position in a list that fewer people are reading from top to bottom. We record it, but the number that decides whether the work succeeded is the last row of the table. The baseline for every row is written down before the change, and the comparison is shown to you at the agreed interval, including rows that did not move. | Group | Metrics | Source | | --- | --- | --- | | Search | Impressions, clicks, click-through rate, average position, indexed pages, and the number of distinct queries the site appears for | Google Search Console, read weekly by a script that only reads | | AI | Referrals from ChatGPT, Perplexity, Copilot and Gemini; citations and cited pages in Bing’s AI Performance report; a fixed set of questions put to Google’s AI Mode, ChatGPT and Perplexity each week, with the answers recorded against what the site says | Analytics referrers, Bing Webmaster Tools, and a human probe with a written protocol | | Content | Time on the page, scroll depth, movement from this page to the next one, clicks on the two calls to action, return visits | Analytics, with events defined before release | | Business | Inquiries; inquiries that name what they read; inquiries that become a scoped quote; conversion rate; assisted conversions where this page was in the path | The contact form and a ledger we keep by hand | ## Questions we expect, answered the way we would answer them on a call **What is the difference between SEO, AEO and AIO?** SEO makes a page discoverable, crawlable, understandable and indexable by a search engine. AEO makes the information on it usable as material when a search or AI service answers a question. AIO organises the facts about a company, its services, people, products and prices, and the relations between them, so that an AI is unlikely to misread them. They are not three products. They share one foundation, which is a correct information structure, and that is what we design. **We already publish SEO articles every month. Why does nothing change?** Because the articles sit on top of a site that never states plainly what the company is, what it sells, to whom, and at what price. A search engine can rank an article and still have no clear entity to attach it to. We fix the entity first. Articles written after that have something to point at. **Will you get us cited by ChatGPT or shown in Google AI Overviews?** No one can promise that, and we do not. Google states that there are no additional requirements or special markup for AI Overviews and AI Mode; a page has to be indexed and eligible for a snippet, like any other. OpenAI documents that OAI-SearchBot decides what can appear in ChatGPT search. What we can do is make sure every one of those systems can fetch your pages, read the facts without running JavaScript, and find the same answer in every place it looks. Whether they then cite you is their decision, and we measure it rather than promise it. **Is llms.txt worth adding?** It costs nothing, so we generate one, but we do not sell it as a result. In June 2025 Google's John Mueller wrote that no AI system currently uses llms.txt, and OpenAI's crawler documentation does not mention it. We treat it as a signpost that says where to read what, and we keep the facts themselves in the pages and in the fact ledger, where crawlers already look. **We implemented schema.org structured data and saw no effect. Why?** Two usual reasons. The markup describes things that are not visible on the page, which Google's policies say not to do, or it describes the page correctly but the page itself is vague, so the markup is precise about nothing. Structured data can only restate what the page already says clearly. We write the page first, then mark it up, and we generate both from the same source so they cannot drift apart. **Our service is new and there is no keyword for it yet. Does any of this apply?** This is the case where it applies most. When no one searches for the category, the only route in is through questions: what does this company do, who is it for, what does it replace. A site that answers those in plain sentences, with the relations between company, service, problem and evidence written down, gives a search engine and an assistant something to reason from. We are in that situation ourselves, and this site is how we handle it. **Do you rebuild the whole site, or work with what we have?** Either. The audit says which. Often the fix is structural and editorial rather than visual: one page per entity, a table where a paragraph was, the price in text instead of a PDF, one founding date instead of two. If the current platform cannot serve crawlable HTML without JavaScript, we say so and quote the alternative. **What does it cost, and how long does it take?** It is quoted in writing for an agreed scope before work starts, tax excluded; there is no published floor. The audit that opens every engagement is free and comes back as a written document. A single landing page is typically weeks, not months; a full site depends on how many entities it has to describe, and the audit gives that number. **How do we know it worked?** We write the baseline down before the change: impressions, clicks, position and query count from Search Console; referrals from AI assistants in analytics; citations in Bing's AI Performance report where available; and the number of inquiries that mention what they read. Then we compare. Rankings alone are not the goal, and we say when a number has not moved. --- source: https://www.tech-japan.jp/services/kintone/ markdown: https://www.tech-japan.jp/services/kintone/index.md updated: 2026-10-14 # kintone already holds the records. The paper around it does not. Building kintone apps is the easy half. The half that decides whether anything improves is what happens at the edges: the paper that still gets retyped, the free-text fields nobody can query, and the four apps a person moves data between by hand every morning. ## Four attachment points, in order of payback *Figure: Where AI attaches to kintone. Paper enters through AI-OCR instead of being retyped. A language model reads free-text fields. An agent moves records between apps on a schedule. Search runs over the kintone data as a knowledge base. kintone itself remains the system of record.* ```text +================================+ paper --OCR--> | | | kintone | --> reports email --LLM--> | still the system | | of record | --> alerts other --API--> | | systems +====================+ ^ | | v agent search moves over your own records data, as a nightly knowledge base ``` ### 1. Paper enters without being retyped AI-OCR reads delivery notes, inspection sheets, order forms and timecards straight into kintone records. The measurable effect is not the typing time; it is the transcription errors that stop happening, and the fact that the record now exists on the day of the event rather than at month end. ### 2. Free text becomes queryable Remarks fields hold most of what a business actually knows and none of what it can search. A language model can classify, extract and normalize those fields into structured columns — which is when the data becomes reportable rather than merely stored. ### 3. An agent does the morning routine The person who copies yesterday’s records between three apps, checks for missing entries and emails a summary is executing a program. Writing it down as one makes it repeatable and auditable, and gives that person their first hour back. ### 4. Search over your own data Once kintone holds the records, it is also a knowledge base: past cases, decisions, and the reasons behind them. Retrieval over that is subject to everything on the [ontology page](https://www.tech-japan.jp/services/ontology/) — if your terminology is inconsistent, this is the step where you find out. ## What we do - AI-OCR so paper reaches kintone without retyping - Generative AI and LLM integration against kintone records - Data analytics and prediction on the accumulated data - Agent automation across apps - Internal knowledge search over kintone data - External system and API integration - Standard kintone work: process design, app development, customization, and enablement for the people who will run it | | | | --- | --- | | Already on kintone | AI capability can be added incrementally, app by app, without a migration | | Not on kintone yet | We start from the process review and the adoption decision, including whether kintone is the right answer at all | | Price | Quoted per scope, tax excluded. One simple app has a fixed price from JPY 50,000 (see the [Japanese menu page](https://www.tech-japan.jp/ja/small-dev/)). First consultation free | > kintone stays the system of record throughout. Nothing here asks you to move your data somewhere we control. --- source: https://www.tech-japan.jp/services/offshore/ markdown: https://www.tech-japan.jp/services/offshore/index.md updated: 2026-08-29 # Offshore fails at the specification, not at the border. Partner teams in Vietnam, Thailand and Myanmar implement. Requirements, architecture, specification, quality control and acceptance testing stay with us in Japan. You talk to Japan, under one contract, with one accountable side. ## Who does what *Figure: How an offshore engagement is split. Requirements, architecture, specification, quality control and acceptance testing stay with TechJapan in Japan. Partner companies in Vietnam, Thailand and Myanmar implement, unit test and build. The client talks to Japan only, under one contract with one accountable side.* ```text JAPAN . TechJapan PARTNER . VN / TH / MM ------------------ ---------------------- requirements implementation architecture unit test specification build quality control ----> ... acceptance test <---- delivery | v the client talks to Japan. one contract, one accountable side. ``` Nearly every offshore engagement that goes wrong goes wrong the same way: the specification that crossed the border assumed a shared context that did not exist. What arrives is exactly what was written, which is not what was meant, and the argument that follows is unwinnable because both sides are right. So the specification is the deliverable we take responsibility for. It is written to be read by someone who does not share your assumptions, and it is the same document acceptance testing is run against. Our representative served as CEO of a Thai corporation and we operate our own SaaS across five Southeast Asian countries, which is the experience this is built on rather than a claim about it. ## When this is right, and when it is not ### A good fit - Medium or larger builds where the specification can be settled before implementation - Systems with an ongoing maintenance life, where a standing team is cheaper than repeated onboarding - Work that can be described precisely enough to be tested against ### A bad fit - A few screens. The coordination cost exceeds the build cost, and we will propose direct domestic development or kintone instead - Work whose requirements are genuinely still being discovered — do that phase close to the people who have the questions - Anything where speed of iteration matters more than unit cost | | | | --- | --- | | Countries | Vietnam, Thailand, Myanmar, through partner companies | | Client communication | Japan side only, in Japanese or English | | Quality control | Retained by TechJapan. Acceptance testing is run in Japan against the specification we wrote | | Price | Quoted by scale and team structure. The first consultation is free and includes a rough team plan and cost estimate | --- source: https://www.tech-japan.jp/products/ markdown: https://www.tech-japan.jp/products/index.md updated: 2026-10-14 # Four products. We wrote all of them, and we operate all of them. Specified, designed, built, run and supported in house. Contract work uses the same stack and the same people, which is the only reason we are willing to describe either one honestly. ## What each one is | Product | What it does | Status | | --- | --- | --- | | [Hadano AI Cabinet](https://www.tech-japan.jp/products/hadano-ai-cabinet/) | Local, evidence-first knowledge database for AI agents, served over MCP | In development | | [relay](https://www.tech-japan.jp/products/relay/) | Tells each AI coding agent what the other agents will do and have done, as facts, never commands. Hadano AI Cabinet series | Production, since September 2026 | | [Pasha Kintai](https://www.tech-japan.jp/products/pasha-kintai/) | Attendance management for small Japanese manufacturers, from a photograph of the paper timesheet | Production, since February 2026 | | [MiiHawk](https://www.tech-japan.jp/products/miihawk/) | Shuttle bus dispatch optimization for factories in Southeast Asia | Production | ## Hadano AI Cabinet An evidence-first knowledge base for AI agents: it finds the passage that backs an answer, returns it verbatim from the stored original, then expands around it. For one agent it runs over the Model Context Protocol with the knowledge in one file on that machine; for a team, an optional process you run yourself serves the same database over HTTP with keys and grants. v2 is in development on a storage engine we wrote in C. The retrieval rules are checked by machine before the engine ships, and the same gate is green on Windows x64 and Linux x64. Nothing is installable today, and the specification, measurements and limits are kept at h-c.ai rather than here. Python 3.11 or newer. [How the retrieval works](https://www.tech-japan.jp/products/hadano-ai-cabinet/) [h-c.ai](https://www.h-c.ai/) ## relay Run two AI coding agents on one repository and each works from the tree it last pulled, unaware the other has commits waiting. relay fixes only the awareness: a hook sends *will* before an agent edits a file and *did* after, and relay pushes those facts to the other agents in the project in a median 18.5 milliseconds, on an append-only, hash-chained log. It never merges, locks or assigns; the receiving agent decides. Free for one person on any number of devices. Business is USD 3 per user per month, tax excluded, once a second person joins; Enterprise is USD 1,000 per month for 300 to 500 users. Claude Code first; Codex CLI works. Proprietary, and the record is kept at relay.h-c.ai. [How it works](https://www.tech-japan.jp/products/relay/) [relay.h-c.ai](https://relay.h-c.ai/) ## Pasha Kintai Photograph the paper timesheet with a phone; AI-OCR reads the handwriting and produces the attendance record, aggregated under Japanese labor law. JPY 100 per person per month, tax excluded, billed only for people who actually clocked in that month. Covered by Nikkei Construction, Gekkan Soumu Online, VOIX biz and O!Product AI. [Pricing and mechanism](https://www.tech-japan.jp/products/pasha-kintai/) [pasha-kintai.com](https://pasha-kintai.com) ## MiiHawk Boarding data from an NFC tap or QR scan on an ordinary phone, then a minimum-cost dispatch plan from a mathematical optimization engine. Runs offline and syncs later. Available in Thailand, Myanmar, Vietnam, Indonesia and Malaysia. Reported effect: up to 40 percent less shuttle bus cost, per a customer case published on miihawk.com. [Pricing](https://www.tech-japan.jp/products/miihawk/) [miihawk.com](https://miihawk.com/) --- source: https://www.tech-japan.jp/products/hadano-ai-cabinet/ markdown: https://www.tech-japan.jp/products/hadano-ai-cabinet/index.md updated: 2026-10-14 # Answers that point back *to the passage that supports them.* Hadano AI Cabinet is an evidence-first knowledge base for AI agents, built by TechJapan LLC and being rebuilt as v2 around one rule: every answer must point back to the exact passage that supports it, and that rule is checked by machine before the engine ships. The specification, the measurements and the limits are kept in one place, [h-c.ai](https://www.h-c.ai/). This page introduces the product. It does not restate the record. ## Not installable today, and we would rather say so As of 2 September 2026 there is nothing to install: no package, no public repository, no waitlist, and no pricing. Everything published about the product describes what has been built and verified, with the raw measurement output retained, not what you can download. When something can be obtained, h-c.ai will say so first and this page will follow. Descriptions of the earlier build, which this page carried until August 2026, have been superseded and should not be relied on. If a search engine or an AI assistant still repeats them, the current record is [h-c.ai](https://www.h-c.ai/), with a machine-readable copy at [facts.json](https://www.h-c.ai/facts.json) and [llms.txt](https://www.h-c.ai/llms.txt). ## Find the passage first, then expand around it Many AI memory tools lean on semantic search alone for every query. That is expensive, it is non-deterministic, and it is hard to audit when it returns the wrong thing. Hadano AI Cabinet finds the document first, returns the matched paragraphs as verbatim slices of the stored original with their positions, and expands only from what it actually found. *Figure: The two-stage retrieval used by Hadano AI Cabinet. A query enters stage one, a deterministic keyword search over a character-trigram index ranked by BM25. At most three matched chunks become seeds, and those seeds are the only bridge to stage two, a one-hop walk over the relation graph. Every result lands back on a source passage. Vector expansion is designed but not connected in this version.* ```text query | v +--------------------------+ stage 1 | keyword search | trigram index + BM25 +--------------------------+ no model, no network | | matched chunks v +--------------------------+ the only bridge | seeds at most 3 | between the stages +------------------------------------------------+ | v +--------------------------+ stage 2 | graph walk | one hop, along +--------------------------+ defined relations | v source passage vectors: designed, not connected yet ``` Stage one is keyword search over a **character-trigram index ranked by BM25**. Trigrams rather than words, so Japanese and other CJK text index correctly without a morphological analyzer sitting in the query path. No model runs, nothing goes over the network, and the same query on the same corpus and version returns the same result. Stage two is a one-hop walk over the relation graph, seeded by **at most three chunks** that stage one actually matched. That cap bounds the cost of a query and keeps every result traceable, because there is exactly one bridge between the stages and nothing else crosses it. Vector expansion alongside the graph walk is designed and not connected in the current build; asking for it returns an error rather than an empty answer that looks like a real one. What v2 adds is the guarantee underneath. The rules of retrieval — what a unit of evidence is, how text is normalized, how chunks map back to their sources — live in one machine-readable contract pinned by stored counterexamples, and work on the engine only counts once that checker passes. The contract, the counterexamples and the raw measurement output are published at h-c.ai. ## One agent on one machine, or a team behind one process | Form | What it is | Where the detail is | | --- | --- | --- | | Local | An AI agent talks to the MCP server over standard input and output. The knowledge is one file on that machine. The MCP process opens no network socket and needs no API key and no GPU | [h-c.ai/security](https://www.h-c.ai/security) | | Shared | Optional, and run by you: one resident process owns the database and serves several clients over HTTP. Keys are stored only as hashes, permissions are default-deny by verb and scope, and every request leaves an audit line. There is no hosted service | [h-c.ai/docs](https://www.h-c.ai/docs) | | Tables in | CSV, TSV and XLSX rows are imported one row per document under a key column; re-importing the same key replaces the document | [h-c.ai/docs](https://www.h-c.ai/docs) | | Platforms | Built and tested on Windows x64 and Linux x64, with the same gate green on hosted runners for both. macOS and ARM are untested | [h-c.ai/limitations](https://www.h-c.ai/limitations) | ## Where the facts live, and why they are not repeated here Until August 2026 this page carried its own table of the specification and its own copy of the measurements. Two copies of a record drift, and the stale copy on a corporate site is exactly what search engines and AI assistants pick up and repeat. So the record now has one home. Where anything on this site and anything at h-c.ai disagree, h-c.ai is right. | | | | --- | --- | | Published facts | [h-c.ai](https://www.h-c.ai/) — what is verified, what is in progress, and what is not available | | Machine-readable | [facts.json](https://www.h-c.ai/facts.json) and [llms.txt](https://www.h-c.ai/llms.txt), generated from the same ledger as the pages | | Measurements | [research](https://www.h-c.ai/research) and [benchmarks](https://www.h-c.ai/benchmarks), with raw output retained | | Limits and guarantees | [limitations](https://www.h-c.ai/limitations), [security](https://www.h-c.ai/security) and [reliability](https://www.h-c.ai/reliability) | | Using it | [docs](https://www.h-c.ai/docs) — the interface as it stands, kept in step with the build | As of 2 September 2026, h-c.ai lists nine items as verified, each with raw measurement output retained. They are reproduced here by title only. The wording of each, and anything added since, is at h-c.ai, and a script in this site’s build compares this list with the live facts.json before every deployment. - A machine-readable retrieval contract - Evidence at paragraph level, verbatim - Citations survive re-indexing - Tamper-evident chunk text - One gate for everything - Search evidence is a verbatim slice of the original - Evidence points back to the original file - Shared access with keys and grants - One gate, exercised on Windows and Linux - Spreadsheets become documents ## The work this suits, and the work it does not What decides whether a knowledge base like this belongs in a given line of work is not its size or its speed. It is that an answer arrives with the passage it came from, unchanged, and that the first stage is deterministic: the same question returns the same passage for as long as the corpus and the version are unchanged. Everywhere that property is worth paying for, it is worth paying for because somebody eventually asks why the system said what it said. **Regulated and audited work** is the clearest case. In legal, accounting, insurance and pharmaceutical practice, an answer that cannot be traced to the document it came from is not evidence of anything; it is a suggestion. The auditor’s question is never “is this plausible” but “show me the clause”. Public-sector work has the same shape for a different reason: a decision affecting a citizen has to be explicable to that citizen. **Work that is not allowed to leave the building** is a category rather than an industry, and it is larger than it looks. Defence suppliers, hospitals, corporate legal departments, and overseas subsidiaries on connections that drop for an afternoon all share one requirement: the knowledge stays where it is. The local form runs as one file on one machine with no network socket open; the shared form runs on a machine you choose, and nothing is hosted by us. **Japanese and other CJK document estates** are a fit for a narrower, more technical reason. Indexing by character trigrams removes the morphological analyzer from the query path, and with it a dependency that has to be maintained, tuned per domain, and blamed whenever a search misses. What it does not remove is the need to turn a question into a query: search takes keywords, and a sentence is not a query. Retrieval quality on Japanese has no published benchmark of its own yet, so a pilot on your own documents is the only honest way to find out. > Where this is the wrong tool. If your users ask questions in words that appear nowhere in the documents, the half of stage two you need is the half that is not connected. If you need a sentence typed by a person to work as a query with nothing in between, that belongs to the calling agent today and not to the database. If you need a hosted service, we do not offer one; shared access means running one process yourself. In each of those cases the honest answer is a different design, and we would rather say so here than discover it with you in month three. ## The same argument we make to clients, applied to ourselves Everything on the [ontology page](https://www.tech-japan.jp/services/ontology/) says that retrieval fails upstream of the model, and that the fix is structure: controlled terminology, defined relations, and a path you can trace. Hadano AI Cabinet is that argument compiled into software — a retrieval engine where the traceable path is the architecture rather than a feature bolted on afterwards. It is also why the accounting on this page stops where it does. A knowledge tool that quietly returns a plausible empty answer is worse than one that errors, and a product page that quietly keeps last month’s specification is the same failure in a different place. --- source: https://www.tech-japan.jp/products/relay/ markdown: https://www.tech-japan.jp/products/relay/index.md updated: 2026-10-14 # Two AI agents, one repository, and neither knows what the other just did. relay tells each AI coding agent what the other agents in the project are about to do and have done. It sends facts — *will* and *did* — never commands, and the receiving agent decides for itself. Free for one person. Business plans are USD 3 per user per month once a second person joins. The specification, guide and measurements live at [relay.h-c.ai](https://relay.h-c.ai/); this page introduces the product and does not restate the record. ## Parallel sessions drift apart between commits Run two or more coding agents on the same repository and the failure is always the same shape: each one works from the tree it last pulled, neither knows the other has three commits waiting, and the second one to push overwrites or conflicts. A human team handles this with a glance at the channel. Agents have no channel. The usual fixes are heavier than the problem. Assignment tables go stale the moment a task changes hands. File locks block the agent that was about to do the right thing. Automatic merging makes decisions nobody reviewed. relay does none of those. It only makes sure each agent knows what the others are doing, and leaves the decision where it belongs. ## A hook sends *will* before the edit and *did* after it *Figure: How relay works between two AI coding agents. Agent A is about to edit a file; a hook sends a will event to relay before the edit and a did event after it. relay appends both to a hash-chained log and pushes them to agent B in the same project, with a median delivery of 18.5 milliseconds. Agent B reads them and decides for itself what to do; relay never issues commands, locks files, or merges anything.* ```text agent A relay agent B | | | | hook: will x.js | | |------------------->| append, hash | | |-- A will x.js ----->| | (edits x.js) | | | hook: did x.js | | |------------------->| append, hash | | |-- A did x.js ------>| | | | | | B decides for itself: | | pull, wait, or ask median 18.5 ms, end to end facts, never commands. no lock, no merge. ``` Setup is one package, a sign-in with Google or GitHub, one MCP entry and one hook, about five minutes. From then on the hook reports every edit automatically: *will* before an agent touches a file, *did* after. relay appends each event to a hash-chained log and pushes it to the other agents in the same project, with a median delivery of 18.5 milliseconds end to end in the September 2026 localhost measurement. Seven event kinds cover what a team actually needs to say: *will*, *did*, *cancel*, *ask*, and three replies — *ok*, *ng*, and a free-text *other*. An agent that reads the list before it starts, and again before it commits, sees whose edits overlap with its own and how many commits it is behind. What it does about that is its own call. The log is append-only and can be re-verified from the first entry, so a record that says an agent changed a file cannot be quietly rewritten later. Other people in the project see your relay-issued ID, never your email address, and relay stores which file changed and how, not the code itself. ## Free alone. USD 3 per user per month as a team. | | | | --- | --- | | One person | Free, on any number of devices, for as long as you like | | Business | USD 3 per user per month, tax excluded, charged for everyone once a second person joins the project. Devices are never counted. Card payment, charged on sign-up, monthly in advance | | Enterprise | USD 1,000 per month for 300 to 500 users, with SSO and an audit log | | License | Proprietary. Not open source | | Record | Specification, guide, pricing and measurements at [relay.h-c.ai](https://relay.h-c.ai/), with its own [llms.txt](https://relay.h-c.ai/llms.txt). Where this page and that record disagree, the record is right | ## What it does, and what it deliberately does not | | | | --- | --- | | Clients | Claude Code is the primary target. Codex CLI works. The Claude mobile app and claude.ai connect over remote MCP. ChatGPT can connect but does not yet receive notifications on its own. Gemini is not supported | | Not a fit | If you want work assigned to agents rather than shared between them, that is a delegation protocol such as A2A, not relay. The [side-by-side comparison at relay.h-c.ai](https://relay.h-c.ai/vs-a2a) includes where relay loses | > relay will not merge, rebase, lock a file, resolve a conflict, store your code, or manage tasks. Each of those is a decision, and relay only carries the facts a decision needs. If you are looking for a tool that makes the decision for you, this is the wrong one. ## We run several agents on our own repositories relay exists because we needed it. Our own work runs as several Claude Code sessions in parallel on the same repositories, and the overwrites were ours before they were anyone else’s. It belongs to the same series as [Hadano AI Cabinet](https://www.tech-japan.jp/products/hadano-ai-cabinet/) for the same reason that product exists: an agent should act on facts it can trace, not on a guess about what another agent might be doing. --- source: https://www.tech-japan.jp/products/pasha-kintai/ markdown: https://www.tech-japan.jp/products/pasha-kintai/index.md updated: 2026-10-14 # Photograph the timesheet. *The attendance record writes itself.* Pasha Kintai is attendance management for small Japanese manufacturers who still run on paper and have good reasons to. Photograph the sheet with any phone; AI-OCR reads the handwriting and produces a record aggregated under Japanese labor law. JPY 100 per person per month, tax excluded, and only for the people who actually worked. ## Paper in, defensible record out *Figure: How Pasha Kintai works. A paper timesheet is photographed with an ordinary phone. AI-OCR reads the handwriting into an attendance record, which is aggregated under Japanese labor law. Corrections route to approvers named in advance, and the result exports as PDF, Excel or CSV. Billing counts only the people who actually clocked in that month.* ```text paper timesheet | | photograph it. an angle is fine. | a factory smudge is fine. v AI-OCR --------- reads the handwriting | v attendance record -- aggregated under | Japanese labor law +-- correction --> approver named | | in advance | <------------------+ v PDF / Excel / CSV | v billed for the people who actually worked ``` The photograph does not need to be square to the page, and the sheet does not need to be clean. Both of those constraints were removed because a factory floor produces neither. The hard part was never the OCR call. It was designing an attendance record that stays defensible under Japanese labor law after a machine has filled it in: aggregation that follows the statutes, corrections that route to approvers named in advance, and an audit trail a labor inspector can follow back to the original photograph. ## One plan, and you are billed for use | | | | --- | --- | | Price | JPY 100 per person per month, tax excluded. One plan, every feature | | Setup fee | None | | What is counted | Only users with at least one clock-in or OCR import that month | | Example | Ten active users is JPY 1,000 per month, tax excluded | | A quiet month | Costs nothing. There is also a pause function | | Minimum term | None. Cancel at any time | | Free trial | One month or longer, every feature, no cap on users or uploads, no credit card | Usage-based billing is the point rather than a promotion. Seasonal work, a busy-period-only crew, or a plant that shuts for two weeks in August should not generate an invoice for people who did not work. Attendance software that charges for every registered employee, whether or not they worked that month, quietly punishes seasonal businesses — and those are exactly the businesses paper survives in. ## What it does - AI-OCR for handwritten timecards, photographed on an ordinary phone - Attendance data management and correction - Working-hour aggregation that follows Japanese labor law - Approval workflow for correction requests, with approvers named in advance - PDF, Excel and CSV export - Notification when the statutes change - Integration for licensed labor consultants, added July 2026 - Email support | | | | --- | --- | | Who it is for | Japanese manufacturers with roughly 10 to 50 employees | | Service site | [pasha-kintai.com](https://pasha-kintai.com) | ## Written about by people who are not us - [Nikkei Construction](https://xtech.nikkei.com/atcl/nxt/mag/ncr/18/00008/061000565/), June 2026 issue, page 99, New Products and Services - [VOIX biz](https://voix.jp/biz/news/175506/), 2026-07-27 — launch of the labor consultant integration - [Gekkan Soumu Online](https://www.g-soumu.com/articles/795beea7-85f6-44cb-bd54-87e767200c02), 2026-02-20 - [O!Product AI](https://oproduct.ai/articles/2307351), 2026-02-20 --- source: https://www.tech-japan.jp/products/miihawk/ markdown: https://www.tech-japan.jp/products/miihawk/index.md updated: 2026-10-14 # You are paying for seats nobody sat in. MiiHawk optimizes employee shuttle bus operations for factories across Southeast Asia. Boarding data comes from an NFC tap or a QR scan on an ordinary phone; a mathematical optimization engine turns it into a minimum-cost dispatch plan. Reported effect: up to 40 percent less shuttle bus cost, per a customer case published on miihawk.com. ## Measure who rode, then solve for the fleet *Figure: How MiiHawk works. A rider taps NFC or scans a QR code on an ordinary phone while boarding, which produces real boarding data instead of an assumed headcount. A mathematical optimization engine turns that data into a minimum-cost dispatch plan by choosing the vehicle combination and the fleet size. This is fleet optimization, not GPS route guidance.* ```text rider boards | | NFC tap or QR scan, ordinary phone, | works offline, syncs later v who actually rode -- not the headcount | somebody assumed v +==========================================+ | OPTIMIZER | | which vehicles, how many, | | on which run | | fleet composition, not GPS routing | +==========================================+ | v dispatch plan ----- up to 40% less cost ``` Shuttle contracts are usually sized from a headcount somebody assumed years ago and nobody has re-examined since. The first thing MiiHawk produces is not a saving; it is the evidence of who actually rode, which is frequently the more uncomfortable number. The optimizer then solves for **vehicle combination and fleet size**: which vehicles, how many, on which run. That is a different problem from GPS route guidance, and conflating the two is how shuttle software ends up optimizing turn-by-turn directions for a bus that should not have been dispatched at all. Ghost routes and inflated invoices become visible for the same reason. Once boarding is recorded at the door, a run that carried nobody cannot be billed as if it carried forty people. ## One plan, priced per employee | | | | --- | --- | | Plan | MiiHawk One — a single plan with every feature | | Price | THB 150 per employee per month | | Since when | April 2026. The earlier three-edition structure (Limited / Enterprise / Route Optimizer) was retired in the one-price revision | | Free trial | Fourteen days, every feature, all routes, no cap on registered employees | | Countries | Thailand, Myanmar, Vietnam, Indonesia, Malaysia | | Interface languages | Japanese, English, Thai | | Hardware | None. NFC and QR scanning on ordinary smartphones | | Connectivity | Runs offline as a PWA and syncs when the connection returns | | Service site | [miihawk.com](https://miihawk.com/) | --- source: https://www.tech-japan.jp/works/ markdown: https://www.tech-japan.jp/works/index.md updated: 2026-10-14 # What has shipped, what is in development — with sources. Four products we wrote and operate — three in production, one in development — an award-winning project, and the scope of contract work. Every claim below is something you can use, something a third party published, or a number we measured ourselves and publish with its conditions. ## What those figures mean | | | | --- | --- | | 15 years, 100+ companies | Cumulative record of the representative, [Go Kyono](https://x.com/kyonogo), including his time in IT consulting for listed companies, as Director and CTO, and as CEO of a Thai corporation. It is a person’s record, not the company’s, and we label it that way | | 4 products | Hadano AI Cabinet (in development); relay, Pasha Kintai and MiiHawk (all in production). Specified, built and operated by us | | 4 press features | Nikkei Construction, Gekkan Soumu Online, VOIX biz, O!Product AI. All four are linked below | | 1 award | Legal Data Utilization Award, Digital Agency Law x Digital Hackathon 2025, announced March 2026 | ## Built and operated in house ### Hadano AI Cabinet — in development An evidence-first knowledge base for AI agents, published at [h-c.ai](https://www.h-c.ai/): a character-trigram index ranked by BM25, then a one-hop graph walk seeded by at most three matched chunks, with every hit returned as a verbatim slice of the stored original and served to agents over the Model Context Protocol. Measured at nDCG@10 of 0.58 on SciFact for the keyword stage — a public benchmark, published as a floor rather than a comparison. v2 is in development on a storage engine we wrote in C, tested on Windows x64 and Linux x64, and not installable today; the record is kept at h-c.ai, which the product page links rather than restates. [The technical record](https://www.tech-japan.jp/products/hadano-ai-cabinet/) ### Pasha Kintai — in production since February 2026 Attendance management for small Japanese manufacturers: photograph the paper timesheet, and AI-OCR produces a record aggregated under Japanese labor law, with a correction workflow that names its approvers. Launched February 2026; a labor-consultant integration followed in July 2026. [Pricing and mechanism](https://www.tech-japan.jp/products/pasha-kintai/) ### MiiHawk — in production Shuttle bus dispatch optimization for factories in Thailand, Myanmar, Vietnam, Indonesia and Malaysia. NFC and QR boarding data collected on ordinary phones, then a minimum-cost dispatch plan from a mathematical optimization engine. Works offline and syncs later. Reported effect: up to 40 percent less shuttle bus cost, per a customer case published on miihawk.com. [Pricing](https://www.tech-japan.jp/products/miihawk/) ## Fukko Compass — Legal Data Utilization Award | | | | --- | --- | | Award | Legal Data Utilization Award, Digital Agency Law x Digital Hackathon 2025 | | Announced | March 2026 | | Team | Team Dango, including Go Kyono of TechJapan LLC | | Field | 112 participants across 20 teams; ten teams reached the final | | Source | [Official announcement, Digital Agency](https://www.digital.go.jp/policies/legal-practice/6acf8ad5-3668-4db4-b998-1c20eff10017) | After a disaster, the support a household is entitled to is scattered across national programs, prefectural programs and municipal programs, each defined in its own statute, and nobody in the middle of a disaster is in a position to reconcile them. Fukko Compass reads that legal data, works out which programs apply to a specific household’s situation, and says what to do next and in what order. It is the same problem this company exists to solve, in its most consequential form: the knowledge was public the whole time, and unusable because it was never structured. [How it was built](https://www.tech-japan.jp/blog/hackathon-award/) ## The same stack, pointed at your problem Contract engagements run on the technology and the people that build the products above. That is deliberate: we are unwilling to recommend an architecture we do not operate ourselves. - [Ontology and knowledge graph construction](https://www.tech-japan.jp/services/ontology/) — terminology control, graph design, and retrieval accuracy measured against a fixed gold set - [AI integration](https://www.tech-japan.jp/services/) — three phases, ending in handover on a date agreed at the start - [kintone and AI](https://www.tech-japan.jp/services/kintone/) — AI-OCR, LLM integration, agent automation and search on top of kintone - [Offshore development](https://www.tech-japan.jp/services/offshore/) — partner teams in Vietnam, Thailand and Myanmar, with quality control retained in Japan