DEV Community: 株式会社SOTATEK JAPAN

PHP2Shell: Why Updating Your Application Isn't Enough

株式会社SOTATEK JAPAN — Wed, 28 Oct 2026 09:26:17 +0000

When a security vulnerability is disclosed, developers often start by checking their application dependencies.

Update the framework. Patch the plugins. Review the packages. Deploy the changes.

But what happens when the vulnerability isn't in the application code at all?

That's the problem highlighted by PHP2Shell, a name associated with two critical PHP runtime vulnerabilities disclosed in October 2026.

For teams maintaining PHP applications, the incident is a reminder that application security doesn't stop at the framework or dependency layer.

The runtime itself is part of the attack surface.

What is PHP2Shell?

On October 21, 2026, the PHP development team released security updates addressing two vulnerabilities:

CVE-2026-109618
CVE-2026-109619

Both issues involve internal PHP memory or request-state handling and may lead to remote code execution (RCE) under certain conditions.

Remote code execution is particularly concerning because successful exploitation may allow an attacker to execute unauthorized code within the privileges of the affected process.

Depending on the environment, this could potentially lead to application compromise, credential exposure, unauthorized file modifications, or further attacks against connected systems.

However, exploitability depends on the PHP version, execution environment, and system configuration. The existence of a vulnerable PHP installation does not mean every application can be exploited in the same way.

The difference between application and runtime vulnerabilities

Consider a typical PHP application:

Client
   |
   v
Web Server
   |
   v
PHP Runtime
   |
   v
Application Code
   |
   v
Database / External Services

Developers usually spend considerable effort securing the application layer.

Common practices include:

Input validation
Authentication and authorization
Dependency updates
SQL injection prevention
Cross-site scripting protection
Secure session management

These practices remain essential.

However, they cannot directly fix vulnerabilities in the PHP interpreter itself.

A fully patched application may still run on a vulnerable runtime.

This is why PHP2Shell deserves attention beyond traditional application security reviews.

Why runtime vulnerabilities are easy to overlook

In many organizations, different teams manage different parts of the application stack.

Developers maintain the application.

DevOps engineers manage deployment pipelines and containers.

Infrastructure teams maintain operating systems and servers.

External providers may manage hosting environments.

This division of responsibilities can create gaps.

For example, a development team might regularly update Composer dependencies while assuming the infrastructure team handles PHP security updates.

Meanwhile, the infrastructure team may consider the application runtime outside its maintenance scope.

Neither team necessarily has a complete view of the system.

The result can be a production environment where the application is up to date, but the runtime is not.

Which PHP versions received security fixes?

The PHP project released the following patched versions on October 21, 2026:

PHP branch	Patched version
PHP 8.5	8.5.12
PHP 8.4	8.4.27
PHP 8.3	8.3.36
PHP 8.2	8.2.35

Teams should check the security status of the exact packages used in their environments.

This distinction matters because some Linux distributions and enterprise vendors backport security patches without changing the upstream version number.

A version string alone may not tell the complete story.

For older PHP branches, verify whether your operating system or commercial support provider still supplies security fixes.

If not, planning a migration to a supported runtime should become a priority.

Checking PHP versions in production

A common first step is running:

php -v

This command is useful, but it comes with an important limitation.

It reports the PHP version used by the command-line interface in that environment.

The PHP version handling web requests may be different.

For example, a server could have one PHP version installed for CLI scripts while PHP-FPM uses another version.

A more complete investigation should include:

The PHP version used by the web application
The active PHP-FPM or web server configuration
The operating system package and security advisory
The PHP version inside deployed containers
Any additional PHP runtimes used by background workers

The goal is to identify the runtime actually processing production requests.

Containers don't eliminate runtime vulnerabilities

Containerization makes deployments more reproducible, but it does not automatically make them secure.

Consider a Dockerfile:

FROM php:8.4-fpm

WORKDIR /var/www/html

COPY . .

CMD ["php-fpm"]

The application may be rebuilt regularly, but the security status still depends on the base image used during the build.

A deployment pipeline should not assume that a successful build means the image contains all relevant security fixes.

Teams should verify the resolved image digest, check applicable security advisories, and rebuild and redeploy when a patched image becomes available.

For production systems, it is also useful to maintain an inventory of deployed image digests and their associated applications.

This makes it easier to identify affected services when a runtime vulnerability is disclosed.

Prioritizing remediation

When a critical runtime vulnerability is announced, updating every system simultaneously may not be practical.

A risk-based remediation plan can help.

Step 1: Identify affected assets

Start with systems that use PHP:

Public websites
Customer portals
E-commerce platforms
Internal applications
API services
Containerized workloads
Legacy applications

Identify the PHP runtime and its patch status for each environment.

Step 2: Prioritize exposed services

Internet-facing applications generally deserve early attention because they may be reachable by external attackers.

Systems handling sensitive information or important business operations should also receive high priority.

Internal systems should not be ignored, especially if they are accessible from other potentially compromised environments.

Step 3: Apply vendor-approved fixes

Deploy the relevant patched PHP release or vendor-provided security package.

Before deployment, prepare compatibility tests, backups, and rollback procedures.

For applications that depend on older PHP behavior, test the update in a staging environment whenever possible.

Step 4: Investigate potential compromise

Patching closes the known vulnerability, but it does not prove that the system was never compromised.

Depending on exposure and available indicators, review:

Web server access and error logs
Unexpected process execution
Suspicious file changes
Unusual outbound connections
Authentication and privilege-related events

If suspicious activity is discovered, follow the organization's incident response process.

Step 5: Verify and document

After remediation, verify the effective PHP runtime, confirm the applicable security fix, and run application regression tests.

Record which systems were updated and which remain under investigation.

Can a WAF protect against PHP2Shell?

A Web Application Firewall can provide an additional defensive layer by filtering or blocking certain suspicious HTTP requests.

However, it should not be treated as a substitute for patching a vulnerable runtime.

Runtime-level vulnerabilities may not have reliable, universally applicable request signatures.

A WAF may reduce exposure in some scenarios, but the primary remediation is to apply the relevant PHP or vendor security fix.

Building a better runtime security process

PHP2Shell also raises a broader engineering question:

How quickly can your team identify every application running a vulnerable runtime?

If the answer requires manually contacting multiple teams and searching through servers, there may be an opportunity to improve asset management.

Useful long-term practices include maintaining a software inventory, tracking supported runtime versions, monitoring vendor advisories, scanning container images, and establishing emergency patching procedures.

These practices are not unique to PHP.

The same principles apply to Java runtimes, Python environments, Node.js, web servers, databases, and other components of a modern application stack.

Final thoughts

PHP2Shell illustrates an important distinction in application security.

Keeping your application dependencies updated is necessary, but it is not sufficient.

The runtime, operating system, web server, and deployment environment all contribute to the application's security posture.

For engineering teams, the most valuable lesson is not simply to patch PHP.

It is to build a process that makes vulnerable runtime components easy to identify, prioritize, update, and verify.

A secure application needs a secure execution environment.

Suggested tags: #php #security #webdev #devops

Choosing an AI Development Partner in Vietnam: What Engineering Teams Should Evaluate

株式会社SOTATEK JAPAN — Wed, 21 Oct 2026 10:29:08 +0000

Vietnam has long been associated with software outsourcing, but its technology industry is increasingly involved in more specialized development work, including generative AI, machine learning, computer vision, and AI agents.

For companies planning to build AI-powered applications, Vietnam offers an interesting range of potential development partners.

However, choosing an AI development company requires more than comparing hourly rates or checking whether a vendor has experience with ChatGPT APIs.

The real question is whether a development team can turn an AI prototype into a secure, maintainable application that works within an existing business environment.

Let's look at the technical considerations that matter.

1. AI development is more than model integration

One of the easiest ways to start building a generative AI application is to connect an existing large language model to a user interface.

A simple architecture might look like this:

User
  |
  v
Web Application
  |
  v
LLM API
  |
  v
Generated Response

This works well for experimentation.

But enterprise applications usually need more components.

Consider an internal knowledge assistant that answers questions using company documents.

A production-oriented architecture may look more like this:

           Enterprise Data
                 |
                 v
         Data Ingestion
                 |
                 v
      Processing & Indexing
                 |
                 v
         Search / Retrieval
                 |
                 v
User --> Authentication --> RAG Pipeline
                 |              |
                 |              v
                 |          LLM Service
                 |              |
                 v              v
          Access Control --> Response
                                |
                                v
                        Logs & Evaluation

The model is only one part of the system.

A development partner also needs experience with data pipelines, authentication, APIs, infrastructure, and application architecture.

This distinction is especially important when evaluating companies that advertise generative AI development services.

2. Evaluate the team's experience with production RAG

Retrieval-Augmented Generation (RAG) is a common approach for building AI applications that use private or domain-specific information.

It can help an LLM generate answers grounded in retrieved documents instead of relying exclusively on its pretrained knowledge.

However, implementing RAG involves several engineering decisions.

Document processing

Enterprise data rarely arrives in a consistent format.

Documents may include PDFs, spreadsheets, presentations, scanned files, and records from internal systems.

A development team needs to consider:

Text extraction and document parsing
Chunking strategies
Metadata management
Data synchronization
Document updates and deletion

Retrieval quality

Vector search alone is not always sufficient.

Depending on the application, hybrid search, metadata filtering, or reranking may improve retrieval quality.

The best approach depends on the structure of the data and the questions users are expected to ask.

Access control

A critical requirement is ensuring that users can retrieve only information they are authorized to access.

Permission checks must be enforced by the application architecture, not left to the language model's judgment.

Evaluation

A RAG system should be tested using representative questions and documents.

Useful evaluation dimensions include retrieval relevance, answer correctness, citation quality, latency, and cost.

When selecting an AI development partner, ask how the team evaluates these aspects rather than focusing only on model selection.

3. AI agents introduce additional engineering challenges

AI agents are becoming an increasingly important area of enterprise AI development.

Unlike a basic chatbot, an AI agent may interact with external tools, retrieve information, execute workflows, and perform multiple steps to complete a task.

For example:

User Request
     |
     v
AI Agent
     |
     +--> Retrieve Information
     |
     +--> Call Internal API
     |
     +--> Process Results
     |
     +--> Request Human Approval
     |
     v
Final Output

This creates new requirements.

An agent may need permission to interact with business systems, but those permissions must be carefully controlled.

Developers should consider:

Tool access and authorization
Input and output validation
Error handling and retries
Human approval for sensitive actions
Audit logs
Monitoring and cost controls

It is also important to distinguish between workflows that genuinely benefit from agentic behavior and tasks that can be handled more reliably through conventional automation.

A capable AI development partner should be able to explain when an AI agent is appropriate—and when it is not.

4. Look for experience beyond AI models

Many enterprise AI projects involve existing applications and infrastructure.

An organization might want to integrate AI into a CRM, ERP, customer support platform, or internal knowledge system.

This requires more than machine learning expertise.

A development team may need capabilities in:

Area	Why it matters
Backend development	Connect AI services with business logic
API integration	Exchange data with existing systems
Cloud infrastructure	Deploy and scale AI applications
Data engineering	Prepare and manage enterprise data
Security	Protect sensitive information and system access
DevOps / MLOps	Monitor, deploy, and maintain applications

This is one reason why established software engineering companies can be relevant partners for enterprise AI projects.

Their experience with application development and system integration can complement their AI capabilities.

5. Vietnam's AI development ecosystem

Vietnam has several technology companies working across AI, software engineering, and digital transformation.

FPT Software is known for global IT services and enterprise digital transformation. CMC Corporation works across AI, cloud, data, and cybersecurity. Viettel combines telecommunications and digital infrastructure with technology development, while VinAI is associated with AI research and computer vision.

Another example is SotaTek Japan, a Vietnam-based technology company operating in Japan through SotaTek Japan.

Its work covers generative AI, AI agents, software development, cloud technologies, and enterprise system integration.

SotaTek Japan also develops its own AI products, including:

SotaAgents: An enterprise AI agent platform
NoteX: An AI-powered meeting and knowledge management platform
Saydi: A real-time AI speech translation service

For engineering teams evaluating development partners, this combination of AI application development and broader software engineering capabilities is worth examining.

It illustrates why vendor selection should consider the complete implementation process, not just the ability to build a model demonstration.

For a broader overview of companies operating in Vietnam's AI ecosystem, SotaTek Japan has published a Japanese-language guide:

AI Development Companies in Vietnam: Company Overview and Selection Criteria

6. Questions to ask before starting a project

Before choosing an AI development partner, engineering teams should prepare a few practical questions.

Architecture

Can the team explain the proposed system architecture and its trade-offs?

Security

How will sensitive data, user permissions, and external AI services be managed?

Evaluation

What metrics will determine whether the AI system performs adequately?

Integration

Can the solution connect with existing enterprise applications?

Production readiness

How will the application handle monitoring, failures, updates, and ongoing costs?

Ownership

Who will own the source code, infrastructure configuration, and project documentation?

The answers will reveal much more than a general statement about AI expertise.

Final thoughts

Vietnam is becoming an increasingly relevant location for AI application development, supported by its software engineering ecosystem and growing interest in advanced AI technologies.

But choosing the right partner is fundamentally an engineering decision.

A successful enterprise AI application requires reliable architecture, data integration, security, evaluation, and long-term maintenance.

Whether the development team is based in Vietnam or elsewhere, these requirements remain the same.

The best AI development partner is not necessarily the one that can produce the most impressive demo. It is the one that can help turn a useful idea into a reliable production system.

Suggested tags: #ai #generativeai #softwaredevelopment #architecture

Japan's AI Market Is Growing Fast. Why Is Enterprise AI Still Hard to Scale?

株式会社SOTATEK JAPAN — Wed, 14 Oct 2026 10:40:40 +0000

Japan's AI market is expanding rapidly.

According to IDC Japan, domestic AI spending is projected to increase from approximately JPY 2.37 trillion in 2025 to JPY 6.89 trillion in 2029.

That's nearly 2.9x growth in just four years.

But market growth doesn't necessarily mean enterprise AI systems are becoming easier to deploy.

For engineering teams, the real challenge is often not selecting an LLM.

It's connecting AI to existing infrastructure, internal knowledge, security policies, and business workflows.

Let's explore why.

1. AI Adoption and AI Production Are Different Problems

Getting started with generative AI is relatively straightforward.

A developer can call an LLM API, send a prompt, and receive a response.

A basic prototype might look like:

def summarize_document(llm, document):
    return llm.generate(
        prompt=f"Summarize this document:\n{document}"
    )

But a production application needs much more.

For example:

Authentication and authorization
Data access controls
Observability and logging
Cost monitoring
Evaluation and testing
Error handling
Human review for sensitive actions

A working AI prototype proves that the model can perform a task.

It does not automatically prove that the application is ready for enterprise deployment.

2. Legacy Systems Create Integration Challenges

Many Japanese enterprises operate business-critical systems that have evolved over decades.

These systems may include:

On-premises databases
Legacy ERP applications
Custom business software
File-based integrations
Systems with limited API access

Introducing AI into this environment requires more than connecting a chatbot to a model.

Consider an internal AI assistant that needs to answer questions about customer orders.

The architecture might look like:

Employee
   |
   v
AI Application
   |
   v
Authentication / Authorization
   |
   v
Data Access Layer
   |
   +---- CRM
   |
   +---- ERP
   |
   +---- Internal Documents
   |
   v
LLM / RAG
   |
   v
Response

Without a reliable data access layer, even a powerful LLM may not be able to provide useful answers.

This is why enterprise AI often becomes a systems integration project.

3. RAG Helps, but It Doesn't Solve Everything

Retrieval-Augmented Generation (RAG) is a common approach for connecting LLMs to enterprise knowledge.

Instead of relying entirely on the model's pretrained knowledge, RAG retrieves relevant information before generating an answer.

A simplified pipeline:

User Query
    |
    v
Query Processing
    |
    v
Document Retrieval
    |
    v
Relevant Context
    |
    v
LLM
    |
    v
Grounded Response

This can be useful for internal documentation, technical manuals, and knowledge bases.

However, RAG introduces additional engineering challenges.

Data quality

Outdated, duplicated, or inconsistent documents can produce unreliable results.

Access control

Retrieval must respect document-level permissions.

Evaluation

Teams need to measure retrieval quality and answer accuracy separately.

Maintenance

The knowledge base must be updated when source documents change.

In other words, RAG is an architectural component, not a complete enterprise AI strategy.

4. AI Agents Add Another Layer of Complexity

AI agents are becoming increasingly important because they can go beyond generating answers.

An agent may plan tasks, call tools, retrieve information, and execute actions.

For example:

User Request
     |
     v
AI Agent
     |
     +---- Search Knowledge Base
     |
     +---- Query CRM
     |
     +---- Analyze Data
     |
     +---- Generate Report
     |
     v
Human Approval
     |
     v
Final Output

This opens new possibilities for business automation.

But it also introduces new risks.

What happens if the agent selects the wrong tool?

What if it attempts an unauthorized action?

How do we prevent duplicate updates?

How can engineers trace the sequence of decisions?

These questions become essential when AI moves from answering questions to executing business operations.

5. Enterprise AI Needs an Evaluation Strategy

One of the biggest differences between AI prototypes and production systems is evaluation.

Traditional software testing often relies on deterministic expectations.

LLM applications are more complicated because outputs can vary.

A practical evaluation framework might include:

Area	Example Metric
Retrieval	Recall@k
Answer quality	Accuracy / Groundedness
Performance	P95 latency
Reliability	Error rate
Operations	Cost per request
Security	Unauthorized access attempts
Business value	Time saved per workflow

Not every application needs every metric.

The important thing is to define measurable success criteria before scaling deployment.

6. Human-in-the-Loop Is an Architectural Decision

Not every AI action should be fully automated.

For low-risk tasks, automatic execution may be acceptable.

For higher-risk operations, human approval may be necessary.

Consider this workflow:

AI Agent
   |
   v
Prepare Customer Response
   |
   v
Policy / Quality Checks
   |
   v
Human Approval
   |
   v
Send Response

The approval step is not simply a temporary limitation.

It can be an intentional part of a secure enterprise architecture.

7. Start With a Workflow, Not a Model

When evaluating enterprise AI opportunities, engineering teams can start with five questions:

What business process needs improvement?
What data does the AI application require?
Which systems must it integrate with?
How will quality and security be evaluated?
What measurable outcome defines success?

Only after answering these questions should teams decide which models, frameworks, and tools to use.

Final Thoughts

Japan's AI market is growing quickly, but enterprise adoption is ultimately an engineering and organizational challenge.

Successful deployment requires more than LLM capabilities.

It requires reliable data integration, governance, evaluation, and workflows that can operate safely at scale.

For a broader overview of Japan's AI market, including market size projections, enterprise adoption trends, and emerging technologies such as AI agents, RAG, multimodal AI, and physical AI, see:

Japan's AI Market Size and Enterprise AI Trends — SotaTek Japan

The next phase of enterprise AI won't be defined only by better models.

It will be defined by how effectively organizations integrate AI into real systems and workflows.

How I’d Build an AI-Powered Workday: From Research to Meetings and Automation

株式会社SOTATEK JAPAN — Fri, 02 Oct 2026 03:26:14 +0000

AI tools are everywhere.
But having access to more AI tools does not necessarily make work more efficient.
You might use one tool for writing, another for research, another for meeting notes, and another for translation. Before long, you have ten browser tabs open and no clear workflow.
A better question might be:

Where does AI actually fit into a typical workday?

Instead of comparing individual tools, let's break a knowledge-work workflow into several stages and look at where different types of AI can help.

1. Research: Use AI to reduce the time to first insight

A typical task often starts with research.
You may need to:

understand a new topic
research competitors
collect industry information
compare products
find supporting sources Traditional search engines are still essential, especially when primary sources matter. But AI-powered search and research tools can reduce the time required to understand a topic initially. A simple workflow might look like:

Question
↓
AI Research
↓
Relevant Sources
↓
Human Verification
↓
Structured Notes

The important part is the Human Verification step.
AI is useful for navigating information, but important facts should still be checked against reliable sources.

2. Writing: Don't ask AI only to "write"

Writing is probably the most obvious use case for generative AI.
But asking:
Write an article about X.

is often not the most effective workflow.
AI becomes more useful when the writing process is separated into smaller tasks.
For example:
Research
↓
Outline
↓
First Draft
↓
Rewrite / Edit
↓
Fact Check
↓
Human Review

AI can support almost every stage without necessarily replacing the person responsible for the final output.
For business users, this can apply to:

emails
reports
proposals
blog posts
social media
internal documentation The biggest benefit may not be "AI writes everything." It may simply be removing the blank-page problem.

3. Meetings: Turn conversations into structured information

Meetings generate a surprising amount of unstructured data.
People discuss problems, make decisions, assign tasks, and share knowledge.
Then someone has to convert all of that into documentation.
AI meeting tools can change the workflow from:
Meeting
↓
Manual Notes
↓
Write Minutes
↓
Share

to something closer to:
Meeting
↓
Transcription
↓
AI Summary
↓
Decisions + Action Items
↓
Knowledge Base

Tools such as NoteX, for example, are designed around AI-assisted meeting transcription, summarization, and knowledge management.
The interesting part is not just saving time on meeting minutes.
Once meetings become searchable data, information that would normally disappear into someone's notebook can become reusable organizational knowledge.

4. Translation: AI as a communication layer

Translation is another area where the workflow is changing.
Traditional machine translation usually works like this:
Source Text → Translation → Target Text

But business communication often happens in real time.
Think about:

international meetings
sales calls
conferences
customer support
distributed teams In these cases, waiting to translate something after the conversation is less useful. Real-time AI speech translation tools such as Saydi attempt to make translation part of the communication layer itself: Speech ↓ Speech Recognition ↓ AI Translation ↓ Translated Output

This is a different use case from simply translating a document.
The goal is to reduce friction while communication is happening.

5. Content Creation: Move from blank canvas to editable draft

AI can also support the creation of:

presentations
images
diagrams
videos
marketing assets The workflow changes from: Idea → Create Everything Manually → Final Asset

to:
Idea
↓
Prompt / Input
↓
AI-generated Draft
↓
Human Editing
↓
Final Asset

That distinction matters.
For professional work, the first AI-generated result usually should not be treated as the final deliverable.
AI is often more valuable as a draft-generation layer.

6. Automation: Move beyond individual AI tools

So far, each AI has supported a specific task.
But there is another direction:
AI agents.
Instead of asking AI to generate a single output, an agent can potentially work across multiple steps.
For example:
User Request
↓
Understand Goal
↓
Search Internal Knowledge
↓
Reason / Plan
↓
Call External Tools
↓
Execute Task
↓
Return Result

In enterprise environments, this becomes particularly interesting when AI can connect with:

internal knowledge bases
databases
APIs
CRM systems
ERP systems
business applications Platforms such as SotaAgents are built around this idea: connecting enterprise knowledge and workflows with AI agents. This moves AI from:

Help me complete this task
toward:

Help execute this workflow.
One workflow, multiple types of AI
Putting everything together, an AI-supported workday could look something like this:
┌─────────────────┐
│ Research │
│ AI Search │
└────────┬────────┘
↓
┌─────────────────┐
│ Writing │
│ Generative AI │
└────────┬────────┘
↓
┌─────────────────┐
│ Meeting │
│ Meeting AI │
└────────┬────────┘
↓
┌─────────────────┐
│ Communication │
│ Translation AI │
└────────┬────────┘
↓
┌─────────────────┐
│ Creation │
│ Generative AI │
└────────┬────────┘
↓
┌─────────────────┐
│ Automation │
│ AI Agents │
└─────────────────┘

This also explains why asking "Which AI tool is the best?" is not particularly useful.
A research tool and a meeting assistant solve completely different problems.
The better question is:

Which part of my workflow am I trying to improve?

Start with the bottleneck, not the tool

There will always be another new AI product to try.
Instead of continuously adding tools, I'd start by identifying repetitive work:
What takes time?
↓
Can AI assist it?
↓
What capability is needed?
↓
Which tools provide it?
↓
Test with a small workflow
↓
Measure the result

This keeps AI adoption connected to an actual problem rather than the popularity of a particular product.
If you're looking for specific products to experiment with, SotaTek Japan has also put together a list covering generative AI, AI search, meeting assistants, translation, content creation, and AI agents:
👉 10 AI Tools for Work: Generative AI, AI Agents, and Productivity Tools
The AI stack for work probably won't be one universal assistant.
It will increasingly look like a combination of specialized AI tools connected around the workflows we already use.

How to Assess a Legacy System Before Modernization: 7 Technical Checkpoints

株式会社SOTATEK JAPAN — Wed, 09 Sep 2026 08:59:19 +0000

Legacy modernization is often discussed as a migration problem:

“Should we move this system to the cloud?”
“Should we rewrite it from scratch?”
“Should we replace the old technology stack?”

But before answering these questions, there is a more fundamental one:

Does the system actually need to be modernized?

A system being 10 or 15 years old does not automatically mean that it should be replaced. If it is stable, secure, maintainable, and still supports business requirements, continuing to operate it may be a reasonable decision.

The problem is that technical debt is not always visible from the outside.

Here are seven technical checkpoints that can help determine whether a legacy system has reached the point where modernization should be considered.

1. Maintenance effort is increasing

Look beyond the annual maintenance budget.

A legacy system may become expensive because even small changes require significant engineering effort.

For example:

A simple feature requires changes across multiple modules
Regression testing takes longer than development
Engineers need to understand undocumented dependencies
Incident resolution requires senior engineers
Old technologies are increasingly difficult to staff

When maintenance effort continuously increases, the system may be accumulating technical debt faster than the organization can manage it.

2. Knowledge is concentrated in a few people

One of the most underestimated risks is knowledge silos.

If only one or two engineers understand how critical parts of the system work, the organization has an operational dependency that is difficult to measure financially.

This becomes especially problematic when:

Documentation is incomplete
Business logic exists only in source code
System behavior depends on undocumented workarounds
Original developers are no longer available

Before modernization, it is worth mapping where critical system knowledge actually exists.

3. Components have reached EOL

Check the lifecycle status of the entire technology stack.

This includes:

Operating systems
Databases
Application servers
Frameworks
Middleware
Third-party libraries

An application can still “work” while some of its underlying components are no longer supported.

EOL does not necessarily mean an immediate full rewrite is required, but it should increase the priority of technical assessment and risk mitigation.

4. Integration has become difficult

Modern applications rarely operate in isolation.

They need to communicate with SaaS platforms, cloud services, mobile applications, data platforms, and increasingly AI systems.

Legacy environments can create integration problems when they rely heavily on:

Batch processing
File-based interfaces
Custom point-to-point integrations
Proprietary protocols
Databases shared directly between applications

A useful question is:

How difficult would it be to integrate this system with a new service today?

If the answer is “very difficult,” the integration architecture itself may be a modernization target.

5. MTTR is getting longer

Mean Time to Recovery (MTTR) is another useful indicator.

When an incident occurs, measure how long it takes to:

Detect the problem
Identify the affected component
Find the root cause
Implement a fix
Restore normal operation

Long MTTR can indicate that the system has become too complex, poorly documented, or difficult to observe.

Modernization should therefore not only focus on infrastructure. Observability and operational architecture can be equally important.

6. Small changes require large amounts of work

A healthy architecture should allow teams to make relatively isolated changes.

In a tightly coupled legacy system, however, changing one function may affect many unrelated components.

This creates the classic situation:

Small requirement → large impact analysis → extensive regression testing → long release cycle

If this happens repeatedly, the architecture may be limiting the speed of the business.

This is often a stronger modernization signal than the age of the technology itself.

7. Security is becoming harder to maintain

Security should be evaluated as an ongoing capability, not a one-time checklist.

Consider whether the organization can still:

Apply security patches promptly
Upgrade vulnerable dependencies
Maintain modern authentication
Perform vulnerability assessments
Control access appropriately
Monitor suspicious activity

If basic security maintenance is becoming increasingly difficult because of the legacy architecture, modernization may become a risk-management requirement rather than simply an IT improvement.

Don't jump directly to a full rewrite

Finding several problems does not automatically mean:

“Rewrite everything.”

There are several possible strategies.

Keep and maintain

If the system is stable and business-critical risks are low, continued maintenance may still be the best option.

Partial modernization

Replace or refactor only high-risk components while keeping the rest of the system.

API-based integration

Expose selected capabilities through APIs so that newer applications can interact with the legacy environment without immediately replacing it.

Cloud migration

Move workloads to cloud infrastructure when the main limitation is infrastructure rather than application architecture.

Full replacement

Consider a complete rebuild when technical debt, security risks, operational costs, and business constraints have accumulated to the point where incremental changes are no longer practical.

A risk-based approach works better

One useful way to think about legacy modernization is to evaluate the system across several dimensions:

              Business Impact
                    ↑
                    |
          High Risk |  Modernize
                    |
                    |
          Low Risk  |  Maintain / Monitor
                    |
                    +----------------→
                       Technical Risk

The goal is not to make every old system “modern.”

The goal is to identify which parts of the system create unacceptable technical or business risk and prioritize them.

This approach can also reduce migration risk because modernization can be performed incrementally instead of through a single large-scale replacement project.

Final thoughts

Legacy modernization should start with assessment, not technology selection.

Before choosing Kubernetes, cloud infrastructure, microservices, or a completely new application stack, first understand:

Where the technical debt exists
Which components create business risk
How difficult the system is to maintain
What prevents integration with modern technologies
Which parts actually need to change

A detailed assessment of these factors can make the modernization roadmap much more realistic.

For a more comprehensive checklist covering these seven areas and how to choose between maintenance, partial modernization, cloud migration, and full replacement, see:

👉 Legacy System Assessment: 7 Checkpoints to Determine Whether Modernization Is Necessary

The key takeaway is simple:

Don't modernize a legacy system just because it is old. Modernize when its technical debt and risks start limiting the business.

How to Introduce Generative AI into Legacy Systems Without Replacing Everything

株式会社SOTATEK JAPAN — Tue, 25 Aug 2026 08:11:52 +0000

Many enterprises want to adopt generative AI, but their existing legacy systems often become a major obstacle.

Core banking systems, ERP, CRM, manufacturing systems, and internally developed applications may have limited APIs, fragmented data, outdated architectures, or poorly documented business logic.

This often leads to a common assumption:

We need to modernize the entire system before we can introduce AI.
In practice, that is not always necessary.

Generative AI can often be introduced incrementally, while keeping existing systems in place.

The challenge of connecting AI to legacy systems

Legacy environments usually have several characteristics that make AI integration difficult:

Limited or no APIs
Data distributed across multiple systems
Undocumented business logic
Outdated databases and applications
Strict security and access-control requirements
Heavy dependence on individual system experts

These challenges are real, but they do not necessarily mean that the entire system needs to be replaced.

Instead, organizations can choose different integration patterns depending on the business use case and the existing architecture.

1. API Integration

If the legacy application already exposes APIs, AI applications can be built on top of the existing system.

A simplified architecture could look like this:

User
↓
AI Application
↓
API Layer
↓
Legacy ERP / CRM / Core System

For example, an AI application could retrieve customer information from an existing CRM and generate a summary for a support agent.

Other potential use cases include:

Customer information summarization
Inquiry classification
Report generation
Business data analysis
Internal workflow support

The advantage is that the core system does not necessarily need to be replaced. AI becomes an additional layer around the existing architecture.

2. RAG for Internal Knowledge

Not every AI use case requires direct access to transactional systems.

Many organizations already have large amounts of useful information stored in:

Technical documentation
Internal manuals
FAQs
Operation procedures
Design documents
Incident reports
Historical records

This is where Retrieval-Augmented Generation (RAG) can be useful.

A typical architecture looks like:

Internal Documents
↓
Document Processing
↓
Vector Database
↓
RAG Layer
↓
LLM
↓
User / Chat UI

Instead of asking the model to rely only on its pretrained knowledge, the RAG layer retrieves relevant internal information before generating an answer.

For legacy environments, this can be an attractive starting point because the existing core system may not need to be modified at all.

However, production systems still need to consider document quality, access permissions, retrieval accuracy, logging, and evaluation.

3. AI Agents for Cross-System Automation

A more advanced approach is to use AI agents to interact with multiple existing systems.

For example:

                ┌── ERP
                │

User → AI Agent ────┼── CRM
│
├── Database
│
└── Internal APIs

Instead of simply generating text, an AI agent can determine which information is needed, retrieve data from different systems, and execute predefined actions.

Potential use cases include:

Collecting information from multiple systems
Generating operational reports
Routing internal requests
Supporting approval workflows
Automating repetitive back-office tasks

This approach requires stronger governance than a simple chatbot.

Authentication, authorization, tool permissions, audit logs, and human approval mechanisms should be considered carefully before allowing an agent to perform business-critical actions.

4. Using AI for Legacy System Maintenance

Generative AI does not have to interact directly with the business system to provide value.

It can also be used to improve the maintenance and modernization process itself.

For example, AI can assist with:

Source code analysis
Documentation generation
Code summarization
Impact analysis
Troubleshooting
Knowledge retrieval
Technical knowledge transfer

This can be particularly useful when documentation is incomplete or when knowledge about an old system is concentrated among a small number of engineers.

In this scenario, AI becomes a tool for understanding the legacy environment before larger modernization initiatives begin.

Start with the Business Problem, Not the Technology

One of the biggest mistakes in AI adoption is starting with the question:

How can we connect AI to our legacy system?
A better starting point is:

Which business process should AI improve?
For example:

This approach helps organizations avoid unnecessary system changes and focus investments on areas where AI can deliver measurable value.

AI Adoption and Modernization Can Happen in Parallel

Another important point is that AI adoption and legacy modernization do not necessarily have to be treated as one large project.

A company could start with a relatively small use case:

Identify Business Problem
↓
Select Small AI Use Case
↓
Build PoC / Pilot
↓
Measure Business Impact
↓
Expand AI Usage
↓
Connect with Modernization Roadmap

For example, an organization might start with internal knowledge search using RAG.

After validating the business value, it could expand into workflow automation with AI agents.

At the same time, the technical team can identify which parts of the legacy architecture should eventually be modernized.

This reduces the pressure to replace everything at once.

What Should Be Evaluated Before Implementation?

Before integrating generative AI with a legacy environment, several areas should be assessed:

*System architecture
*
Understand how the existing applications communicate and whether APIs or other integration mechanisms are available.

Data

Identify where relevant data is stored, how reliable it is, and whether it can be accessed safely.

*Security
*
Define authentication, authorization, data protection, logging, and governance requirements.

*Business impact
*
Determine which processes are suitable for AI and define measurable success criteria.

*Future scalability
*
Avoid creating an AI integration that works only for one experiment. The architecture should ideally support future use cases and modernization initiatives.

Final Thoughts

Legacy systems should not automatically become a reason to postpone generative AI adoption.

API integration, RAG, AI agents, and AI-assisted maintenance provide different ways to introduce AI while preserving existing technology investments.

The right approach depends on the condition of the legacy environment and, more importantly, the business problem that needs to be solved.

Instead of asking:

“Do we need to replace our legacy system before using AI?”

it may be more useful to ask:

“Where can AI create value with the systems we already have?”

For a more detailed discussion of legacy systems, generative AI integration patterns, industry use cases, and a step-by-step implementation approach, see:

Generative AI for Legacy Systems: How to Leverage Existing Systems for AI Adoption

SotaTek Japan supports organizations in legacy system assessment, generative AI implementation, AI agent development, and system modernization.

8 Programming Languages for AI Development in 2026: How to Choose the Right One

株式会社SOTATEK JAPAN — Wed, 12 Aug 2026 03:52:43 +0000

AI development is no longer limited to research labs. From manufacturing and finance to healthcare and retail, companies are increasingly integrating AI into their products and business processes.

One of the first technical decisions in an AI project is choosing the right programming language.

Python is often considered the default choice for AI and machine learning, but it is not the only option. Depending on the requirements, languages such as C++, Java, JavaScript, Julia, and others can play important roles.

Here is a practical overview of eight programming languages used in AI development.

Python — Best for General AI Development

Python has become one of the most widely used languages for AI and machine learning.

Its ecosystem includes frameworks and libraries such as PyTorch, TensorFlow, scikit-learn, and OpenCV, covering deep learning, machine learning, natural language processing, and computer vision.

Python is particularly useful when teams need to build and iterate on AI models quickly.

*Best for:
*

Machine learning
Deep learning
NLP
Computer vision
AI prototyping

R — Statistical AI and Data Analysis

R is designed around statistics and data analysis.

It can be useful for predictive modeling, statistical analysis, visualization, and research-oriented AI projects.

*Best for:
*

Statistical modeling
Data analysis
Predictive analytics
Research

Java — Enterprise AI

Java remains relevant for organizations that need to integrate AI into existing enterprise systems.

Its mature ecosystem, portability, and scalability make it suitable for large backend systems and AI applications that need to work with existing Java-based infrastructure.

*Best for:
*

Enterprise AI
Large-scale applications
Backend integration
Production systems

C++ — Performance-Critical AI

When latency and performance are critical, C++ becomes an important option.

It is widely used in computer vision, robotics, autonomous systems, embedded AI, and other environments where direct hardware control and low latency are required.

*Best for:
*

Real-time AI
Computer vision
Robotics
Edge and embedded systems

JavaScript — AI for the Web

JavaScript allows AI functionality to be integrated directly into web applications.

Technologies such as TensorFlow.js make it possible to run machine learning models in browser-based environments and Node.js applications.

*Best for:
*

Web AI
Browser-based inference
Interactive applications
Client-side machine learning

Julia — High-Performance Numerical Computing

Julia is designed for numerical and scientific computing while maintaining a relatively accessible syntax.

It can be considered for AI research and applications where computational performance is particularly important.

*Best for:
*

Scientific computing
Numerical optimization
AI research
Computationally intensive workloads

Prolog — Logic-Based AI

Prolog takes a different approach from mainstream machine learning languages.

It is designed around logic programming and can be useful for rule-based reasoning, expert systems, constraint solving, and symbolic AI.

*Best for:
*

Expert systems
Rule-based reasoning
Constraint solving
Symbolic AI

Lisp — Symbolic AI and Research

Lisp has a long history in artificial intelligence research.

Although it is no longer a mainstream choice for modern deep learning, Lisp and its dialects can still be relevant to symbolic processing, knowledge representation, and specialized AI research.

*Best for:
*

Symbolic AI
Knowledge representation
Expert systems
AI research

There Is No Single “Best” Language for AI

The right choice depends on what you are building.

Requirement	Possible choice
AI prototyping	Python
Machine learning	Python
Statistical analysis	R
Enterprise integration	Java
Real-time AI	C++
Web-based AI	JavaScript
Numerical computing	Julia
Rule-based reasoning	Prolog / Lisp

In real-world AI systems, using multiple languages can also make sense.

For example, a team may use Python for model development, C++ for performance-critical inference, and Java or Go for backend services and APIs.

This means language selection should be considered together with the AI framework, deployment environment, system architecture, existing infrastructure, and long-term maintenance requirements.

Final Thoughts

Python remains a strong default choice for many AI projects because of its ecosystem and developer community. However, performance requirements, enterprise integration, deployment environments, and the type of AI application can make other languages a better fit.

The most effective approach is not to ask “Which programming language is the best for AI?”, but rather:

Which language is best suited to this particular AI system?
For a more detailed comparison of AI programming languages and their use cases, see:

👉 [8 Programming Languages for AI Development in 2026]

SotaTek Japan provides AI system development, AI agent development, AI voice translation, and AI Vision solutions for enterprise applications.

👉 Explore SotaTek Japan AI Solutions

生成AI vs AIエージェント：違いと使い分け、ビジネスへの最適活用法

株式会社SOTATEK JAPAN — Fri, 25 Jul 2025 08:12:02 +0000

近年、急速に進化を遂げるAI技術の中でも、「生成AI（Generative AI）」と「AIエージェント（AI Agent）」は特に注目を集めています。どちらも業務効率化や付加価値向上に貢献する技術でありながら、それぞれ異なる特性と用途を持っています。本記事では、生成AIとAIエージェントの違いを明確にし、それぞれのユースケースや導入方法、活用のポイントを詳しく解説します。

生成AIとは？

生成AI（Generative AI）は、自然言語処理や画像認識などの深層学習モデルを活用して、新しいテキスト・画像・音声・動画などのコンテンツを生成するAI技術です。

特徴

入力に基づいて新しいコンテンツを生成
パターン認識と学習に優れ、柔軟な出力が可能
自然言語・コード・画像・動画など、あらゆる形式のコンテンツに対応

主なユースケース

AIエージェントとは？

AIエージェントとは、目標に基づいて複数のタスクを自律的に実行し、意思決定を行うAIシステムのことです。単なる応答型AIではなく、状況を認識し、計画を立てて行動する「エージェント的思考」を持ちます。

特徴

マルチステップなタスクの自動化が可能
目的志向型で、自律的な行動を取る
外部ツールやAPIとの連携により、実行力が高い

主なユースケース

生成AIとAIエージェントの違い

両者の補完的な活用

生成AIとAIエージェントは、組み合わせて使うことでより大きな効果を発揮します。
例1：営業活動の自動化

生成AI：営業メール文面の作成
AIエージェント：ターゲット抽出 → メール送信 → 開封状況の把握 → フォローアップ
例2：レポート作成
生成AI：文章やグラフの自動生成
AIエージェント：必要なデータ収集 → 分析ツールの起動 → レポート送付まで自動化

導入のポイントと課題

まとめ

生成AIとAIエージェントは、それぞれ異なる強みと可能性を持った技術であり、補完的に活用することで業務効率や付加価値を大きく向上させることが可能です。生成AIは、創造的なコンテンツ生成や情報整理といった分野で優位性を発揮し、日常業務の負担を軽減します。一方、AIエージェントは、複雑でマルチステップなタスクの自動化や、目標達成に向けた自律的な行動により、ビジネス全体の最適化に貢献します。
今後のAI活用においては、「どの業務に、どのAI技術を、どのように組み込むか」という視点がますます重要になります。単なる自動化を超えた戦略的なAI導入が、企業競争力を左右する時代が到来していると言えるでしょう。
テクノロジーを理解し、それぞれのAIの特性を見極めながら、目的に応じた最適なAI活用戦略を描くことが、これからのビジネスの成功に直結するカギとなります。

SotaTekとSota Holdings：技術エコシステムで加速するデジタル変革

株式会社SOTATEK JAPAN — Wed, 23 Jul 2025 01:48:16 +0000

10年間の歩みの中で、SotaTekは単なるアウトソーシング企業から、最先端のテクノロジーを駆使して世界の課題解決に取り組む“トータルテックパートナー”へと進化を遂げました。SotaTekとその親会社であるSota Holdingsは、多分野にわたるテクノロジー・エコシステムを通じて、国家規模のデジタルトランスフォーメーション（DX）推進に大きく貢献しています。この取り組みは、2024年12月22日に発表された中央委員会の決議第57号に沿った、ベトナム政府のDX戦略に呼応したものであり、Sota Holdingsは中核企業として、革新的なソリューションと現場に即したリソースを結びつけ、社会変革の一翼を担い続けています。

成長を牽引する中核企業：SotaTekの進化

Sota Holdingsは現在、ソフトウェア、ブロックチェーン、AI、IoT、R&D、人材、テック教育など、11の企業で構成されています。各社は独立して運営されながらも、知識とリソースを有機的に結びつけるエコシステムを形成しています。なかでも中核企業であるSotaTekは、日本・韓国・アメリカ・シンガポール・オーストラリア・ベトナムの6ヵ国に拠点を持ち、1,300名以上の専門人材を有しています。主要事業は：

ソフトウェア開発
ブロックチェーンソリューション
AI・ERP・IoT・クラウドサービス
応用研究と製品開発

また、AIによる不動産評価ツール「BASAO Evaluation」では、従来比で評価時間を約90％削減し、業界に大きなインパクトを与えています。Clutch、G2、GoodFirmsなどのプラットフォームでも5つ星評価を獲得しています。

革新の最前線：SotaLabsと研究成果

SotaLabsは、Sota Holdingsにおける研究・試験・製品開発のハブとして機能しています。以下のようなプロダクトをリリース：

ChatWow：自然言語対話AI
ShotX：ビデオ分析ソリューション
Topspot AI：マーケティング支援ツール
RaidenX：ブロックチェーン（Sui）上での高速トランザクション表示（従来比10秒短縮）
NoteX：音声認識精度99.2%、リリース1ヵ月で1,000ユーザー突破

Web3時代への備え：SotaZK

Sota Holdingsは、分散型識別子（Decentralized ID）とWeb3セキュリティへの対応として、SotaZKを設立しました。ZKP（ゼロ知識証明）技術に基づき、ユーザー主導のデータ管理とプライバシー保護の実現を目指しています。

教育・人材：SotaTek EducationとSotaHRの役割

SotaTek Education：ベトナム初、韓国YBMと提携し、国際的なプログラミング資格「COS Pro」を提供。また、実務に即した開発トレーニングを実施。
SotaHR：グループ内外の企業向けに、IT人材の採用・育成・定着支援を行うHRサービスを提供。

さらなる注目企業群

SotaICG & DopikAI：石油・製造業・カスタマーサービスにおけるAIソリューションの展開
BEESOTA6G Alliance：次世代通信（6G）研究に特化
SotaNext & ITSJ-G：ブロックチェーン・エンタープライズ向けソフトウェア開発
Sota Solutions：ERP・CRMによる業務最適化ソリューションの提供

オープンエコシステムモデルと未来構想

Sota Holdingsの真髄は、各企業が専門性を活かしながらも、緊密に連携するオープンエコシステムの構築にあります。グループ全体で知識・人材・リソースを柔軟に共有することで、新たなテクノロジートレンドへの対応力と革新スピードを飛躍的に高めています。 SotaTekとSota Holdingsは、この10周年という節目をひとつの通過点と捉え、次の10年へ向けたさらなる進化と挑戦を加速させていきます。

詳細はこちら：https://www.sotatek.com/jp/

SotaTek、ベトナムの技術で日本に挑む

株式会社SOTATEK JAPAN — Thu, 17 Jul 2025 01:26:40 +0000

SotaTekの10年にわたる信頼構築の歩み

2015年、ベトナム・ハノイにて、情熱を持つエンジニアとビジョナリーたちが、小さなスタートアップとしてSotaTek（State-of-the-Art Technology）を立ち上げました。世界水準のITソリューションをベトナムからグローバル市場へ届けるという大きな志のもとに誕生したこの会社は、今や20カ国以上に展開し、日本市場をはじめとする多くの国で信頼されるテクノロジーパートナーとして成長を遂げています。

創業10周年を迎える今、私たちは単なる成果だけでなく、ここまでの道のりで築いてきた価値観やパートナーシップに、あらためて感謝の意を表したいと思います。

ハノイから世界へ：グローバル志向のスタートアップ精神

ここ数年、ベトナムはアジアで最も有望なテクノロジー拠点のひとつとして急成長を遂げています。若く優秀なIT人材と政府の強力な支援により、ソフトウェア開発やデジタル変革の拠点として注目されています。

その中で誕生したSotaTekは、ブロックチェーンやAI、DX推進支援、Web・アプリ、業務システムなど、先進技術を核としたサービスを展開してきました。
私たちの信条はシンプルかつ明確です：
「最先端の技術で、未来を描く」

日本市場への挑戦——“信頼”が鍵

数ある海外市場の中でも、日本はSotaTekにとって特別な存在です。日本企業は高い品質基準、正確さ、長期的な関係構築を重視しており、それらはベトナム人の勤勉さや誠実さと通じるものがあります。

とはいえ、日本市場への参入には技術力だけでは不十分です。言語、文化、商習慣を深く理解し、現地に根ざした対応力が求められます。

この課題に応えるべく、私たちは東京にSotaTek Japanを設立しました。バイリンガルのエンジニアや、日本のビジネスマナーに精通したプロジェクトマネージャーを揃え、ERPやAI、レガシーシステムのモダナイゼーションなど、日本企業のニーズに合わせたソリューションを提供しています。

「信頼」を積み重ねる——結果よりも関係性を重視

10年間で、SotaTekのチームは20名未満から1,000名超へと成長しました。日本では、スタートアップから中堅・上場企業まで、さまざまな業界・規模のクライアントに対応しています。

私たちの強みは、単なる「開発会社」にとどまらず、共に課題を解決するパートナーとして寄り添う姿勢にあります。アジャイル開発によるスピード感ある対応、徹底した情報セキュリティ、そして透明性のあるコミュニケーションが、日本企業の皆様から高く評価されています。

10年以上の実績を持ち、1300名以上のエキスパートが、銀行、金融、保険、自動車などの分野で最適なITサービスを提供。500以上のプロジェクトを成功に導き、25か国以上に展開しています。

日本でのいくつかのプロジェクト事例：

AIベースの美容アプリケーション
クリニック向け電子カルテシステム
製造業向けソリューション
日本のSIer様との協業による中小企業向けDX支援

それぞれの案件が、日本のビジネス文化への理解を深め、信頼を築く礎となっています。

10年の軌跡、そして未来へ

10周年はひとつの節目であると同時に、新たなスタートでもあります。

日本のDXニーズが高まる中、SotaTekはより強力なローカル体制、専門性の高い技術力、そしてR&D投資を通じて、次のステージへと進みます。

「信頼されるベトナム発IT企業」として、日本市場でより多くの価値を提供できるよう、挑戦を続けてまいります。

10年のご愛顧に、心より感謝を

この10年、私たちが歩んでこられたのは、共に挑戦し、支えてくださったクライアント・パートナー・社員の皆様のおかげです。

SotaTekはこれからもテクノロジーに心を込めて、お客様と共に未来を築いてまいります。

次の10年も、どうぞよろしくお願いいたします。

詳細はこちら：https://www.sotatek.com/jp/

ヘルスケアにおけるブロックチェーン：今後の可能性と課題

株式会社SOTATEK JAPAN — Mon, 14 Jul 2025 02:24:50 +0000

ブロックチェーン技術は近年、医療業界において革新的な可能性を秘めた技術として注目を集めています。特に、ヘルスケア機関間の相互運用性を高め、患者中心の医療サービスを実現する基盤技術としての導入が期待されています。ブロックチェーンは、分散型台帳技術として、一度記録された情報を改ざんできないという特性を有し、医療データの信頼性や透明性の向上、安全な情報共有の実現といった観点から、従来の医療ITインフラを補完・強化する役割が期待されています。

しかしながら、こうした技術的利点がある一方で、ブロックチェーンの導入には依然として多くの課題が残されています。例えば、導入コストの高さ、既存の医療情報システムとの互換性、法規制（特に個人情報保護に関する規制）への対応、さらに医療従事者のITリテラシーや運用体制の整備といった、現場レベルでの実装を阻む障壁が存在します。

本稿では、ブロックチェーン技術のヘルスケア分野への応用可能性を多角的に検討し、その利点と課題について説明します。

ヘルスケアにおけるブロックチェーンとは

ブロックチェーンとは、情報を安全かつ透明に記録・管理するための分散型デジタル台帳技術です。この技術では、情報が「ブロック」として時系列に記録され、暗号技術を用いてそれらが「チェーン」のように連結されていきます。ブロックチェーンの最大の特徴は、一度記録された情報は改ざんが極めて困難である点にあり、金融分野では暗号資産（ビットコインなど）や送金履歴の管理、契約の自動化などに広く活用されています。

このようなブロックチェーン技術は、近年、医療・ヘルスケア分野にも応用が進んでいます。ヘルスケア分野でのブロックチェーンとは、患者情報や医療データを安全・効率的に共有・管理するための手段として導入されつつあるものです。たとえば、電子カルテ（EHR）の改ざん防止、臨床試験データの頼性確保、保険請求手続きの透明化、医薬品の流通経路の追跡、さらにはウェアラブルデバイスから取得される健康データの管理など、多岐にわたる分野での活用が期待されています。

この技術を導入することで、患者主導の医療情報管理が可能となり、医療機関間でのスムーズな情報共有や診療の質の向上、重複検査や医療ミスの削減にもつながります。また、ブロックチェーンによる「スマートコントラクト（自動契約）」機能を使えば、保険請求や診療記録の処理が効率化され、手続きの透明性と迅速性が大幅に向上します。

ヘルスケアにおけるブロックチェーンの必要性

ヘルスケア分野では、技術革新のスピードがますます加速しています。現代社会が求めているのは、高度かつ先進的なテクノロジーに支えられた質の高い医療サービスです。その中で、ブロックチェーン技術はヘルスケア業界を変革する重要な役割を担うと期待されています。

現在のヘルスケア体制は、「患者中心のアプローチ」へと移行しており、常に利用可能なヘルスケアサービスと適切な医療資源の提供という2つの要素が重視されています。ブロックチェーンは、ヘルスケア機関がより質の高いケアを効率的に提供することを可能にします。

また、医療情報交換（HIE：Health Information Exchange）は、手間と時間がかかる反復的な作業であり、医療費の高騰を招く一因でもあります。ブロックチェーンを活用することで、この課題を効率的に解決できます。

さらに、ブロックチェーンを用いれば、国民が健康研究プログラムに参加できるようになり、公共の健康に関する研究やデータ共有が進むことで、地域ごとに最適な治療の実現につながります。現在の医療システムや医療機関では、中央集権型のデータベースによって情報が一元管理されています。

人口健康管理においては、「データ保護」「情報共有」「システム間の連携（相互運用性）」といった課題が大きな障壁となってきました。これらの課題は、ブロックチェーンの導入によって信頼性の高い形で解決できます。適切に導入すれば、セキュリティの向上、データの交換・整合性・相互運用性の確保、さらにはリアルタイムでの更新やアクセスが可能となります。

とくに、個別化医療やウェアラブル機器が普及する中で、データ保護への懸念はますます高まっています。患者や医療従事者にとって、安全かつ簡便にデータを記録・送信・参照できる手段が求められており、こうしたニーズに応える技術としてブロックチェーンの活用が注目されています。

ヘルスケアにおけるブロックチェーンの活用事例

ブロックチェーンは比較的新しい発展中の技術であり、ヘルスケア分野における導入が成功すれば、革新的な応用が期待されています。ネットワーク上のすべての主要なメンバーや医療提供者間で円滑かつ効率的にデータを共有・配信することは、多くの疾患に対する経済的な治療法や高度な治療法の開発につながります。これにより、今後数年間でヘルスケア分野の成長が加速するでしょう。

近年、物流業界におけるブロックチェーン技術の可能性が明らかになっており、それはヘルスケア分野にも応用できる利点を示しています。ヘルスケアは生活の質に直接影響を与える分野であるため、デジタル変革やイノベーションが最初に進展する分野の一つとなっています。同時に、ブロックチェーン技術は主に金融分野で広く利用されるようになっており、ヘルスケア分野においても、科学、物流、医療従事者と患者の関係性など、さまざまな面で重要かつ有望な機会を提供しています。

個人患者情報の保存

臨床研究の各フェーズの前後には、膨大な患者情報や健康データが生成されます。血液検査、品質評価、推定、健康アンケートなど多様なデータがあり、それらの文書や記録の存在を証明する結果が得られる場合があります。医療提供者は保存されたデータの信頼性を確認する必要があり、ブロックチェーンシステム上に保存された元の記録と照合することで容易に検証可能です。ブロックチェーンは既存の暗号技術に基づいており、データ共有に適した暗号的枠組みを提供します。患者の氏名、生年月日、診断、治療内容、通院履歴などは、EHR（電子健康記録）形式で医療提供者によって記録され、クラウドまたは既存のデータベースに保存されます。

特定の処置の効果分析

研究者は検証済みの患者データへアクセスすることで、ある特定の処置が大規模な患者集団に与える影響を効果的に分析できます。これにより、対象患者群に対する管理手法が大きく改善されます。ブロックチェーンインフラが整備されれば、製薬会社はリアルタイムでデータを収集し、個別に最適化された処方薬やサービスを患者に提供できます。ブロックチェーンは、薬局の業務も簡略化し、データに基づいた服薬指導が可能になります。ウェアラブル端末によってリアルタイムに収集されたデータから、医師は患者の現在の状態を把握し、緊急事態に迅速に対応することができます。

検証

トランザクションはブロックチェーンに追加される前に検証され、これはアルゴリズムによって行われます。情報が暗号化され、デジタル署名され、保存されることで、その真正性が確保されます。医療機関、技術革新企業、医療業界は、ブロックチェーン技術が現在何を実現できるか、将来的にどのようにヘルスケアをより安全かつ低コストにできるかについて、さまざまな可能性を模索しています。適切な結果の検証が行えるようになれば、ヘルスケアエコシステムにおいてブロックチェーンは画期的な役割を果たすでしょう。

安全性と透明性

ブロックチェーンは非常に高い安全性と透明性を提供し、医師が患者の治療により多くの時間を割けるようになります。また、希少疾患の臨床試験や治療支援にも貢献します。ヘルスケアソリューション提供者間での円滑なデータ共有により、診断精度、治療効率、医療システムのコスト削減が実現します。医療関連組織が共有の分散型台帳を通じて連携し、安全性と透明性を向上させることが可能です。ユーザーは、別の整合性や機密性の手段を探すことなく、システム内で自身のデータやその他の操作を交換・監視することができます。

健康記録の管理

ブロックチェーンは、ヘルスケア分野における記録保持の理想的な技術となり得ます。ヘルスケアデータの共有、電子健康記録の保持、保険管理、事務処理などの用途があります。患者は専用アプリを通じて自らの健康情報をブロックチェーンネットワークに送信できます。センサーやスマートデバイスとの連携も、デジタルスマート契約によって促進されます。多くの場合、電子健康記録は複数の医療機関に分散しており、ブロックチェーンによってこれらのデータが統合され、患者は過去の履歴にアクセスできるようになります。すべての情報が一か所に集約されることで、患者の健康状態に対する新たな視点が得られ、情報の正当性と信頼性が保たれ、プライバシーも守られます。

臨床試験

臨床試験では、結果の改ざんや目的に合致しないデータの断片化などの問題が発生します。ブロックチェーンは、これらの問題を解決し、臨床試験への信頼を高めるために用いられます。ビジネス分析プラットフォームは市場の動向を調査し、医療分野がどのような可能性を秘めているかを把握できるようにします。製薬チェーンの管理においても、ブロックチェーンの信頼性を活用し、製造元から消費者までの追跡が可能になります。

情報の表示

ブロックチェーンシステムは、医薬品の由来に関する情報を表示し、品質や正規メーカーによる供給を保証します。適切に使用されれば、センシティブなデータに対するかつてないほどの保護を提供できます。金融、小売、不動産などさまざまな分野でブロックチェーンアプリの導入が進み、情報表示の面で多くの利点を得ています。ヘルスケア分野もまた非常に複雑であり、この技術導入には多くの議論を伴います。市場はすでに医薬品、ワクチン、臨床試験、クラウド活用などの分野で根本的な変化を遂げつつあります。

ヘルスケア分野でのブロックチェーン導入の課題

ブロックチェーンのヘルスケア活用がなかなか普及しない背景には、業界特有のいくつかの課題が複雑に絡み合っています。

レガシーシステムの壁

最大の障壁は、既存の医療ITインフラが深く根付いていることです。多くの金融機関がブロックチェーンをゼロから導入できるのに対し、医療機関はこの20年間で電子カルテ（EHR）に莫大な投資を行ってきました。これらのシステムは、しばしば課題が指摘されてはいるものの、現場の業務フローに深く組み込まれており、機関全体にとって重要な基盤です。そのため、これらを入れ替えたり大幅に改修したりすることは、多大なコストと業務上のリスクを伴い、多くの医療機関にとって現実的ではありません。

HIPAA準拠の難しさ

複雑な規制環境も大きなハードルです。理論的には、ブロックチェーンはセキュリティ強化や監査証跡の面でHIPAA（米国医療情報保護法）への準拠をサポートできますが、これを実装するには分散型台帳という前提に合っていない現行の法律を丁寧に読み解く必要があります。単にデータ共有を進めるだけでなく、変化するプライバシー規制に厳密に対応し続けることが求められます。

コストと価値のバランス

コスト面も重要な要素です。ブロックチェーンは長期的にはコスト削減につながる可能性があるとは言われていますが、それはあくまで理論上であり、初期導入には多額の投資が必要です。特に、中小規模の医療機関などは財政的余裕が少なく、明確な短期的な効果が見込めない限り投資判断が難しいのが実情です。

これらの課題は決して克服できないものではありませんが、ブロックチェーンの導入が医療分野で気に進む「革命的変化」ではなく、徐々に浸透していく「進化的な変化」となる理由を物語っています。

今後の展望

医療業界にブロックチェーン技術を組み込むには、特定の課題に対処する必要があります。この先進技術を医療施設で利用する際の最大の問題は、専門知識の不足です。

ブロックチェーンアプリケーションはまだ初期段階にあり、さらなる技術の探求と研究が求められています。ただし、この問題は医療機関だけでなく、医療関連団体や規制当局の責任にも関わってきます。ヘルスケア分野に変革が求められている今、ブロックチェーンの拡大は非常に有望です。ブロックチェーンによる技術革新は、治療プロセスにおける成果と進展を可視化するうえで重要な役割を果たします。ブロックチェーン技術は、情報のやり取りやトランザクションの検証の中核となります。

これからの時代、ネットワークメンバーの同意に基づいて、トランザクションを認証・記録することがブロックチェーン技術によって可能になります。ブロックチェーンは、公開鍵・秘密鍵暗号方式を用いることで、患者単位での数理的なセキュリティを提供し、新世代の医療情報共有の基盤を築きます。

この技術は、患者の医療記録の管理、不正アクセス防止、相互運用性の改善、医療手続きの合理化、処方薬の管理、医療やサプライチェーンの監視といった分野において活躍が期待されます。

よくある質問（FAQ）

ヘルスケアにおけるブロックチェーンはなぜ注目されているのですか？

医療では、患者情報の安全な管理、医療機関間でのデータ共有、保険請求の効率化など、多くの領域で透明性と信頼性が求められます。ブロックチェーンはこれらの課題を技術的に解決できる可能性があるため、特に注目されています。

ブロックチェーンは電子カルテ（EHR）とどう関係していますか？

電子カルテにブロックチェーンを導入することで、診療記録の改ざんを防ぎ、どの医療機関でも正確な情報を共有できるようになります。患者中心の医療の実現にもつながります。

ブロックチェーンを導入することでどのようなメリットがありますか？

主なメリットには以下が挙げられます：

データの改ざん防止・高いセキュリティ
医療機関間のスムーズな情報共有
医薬品の流通の透明化（偽薬防止）
保険請求の自動化・迅速化
臨床試験の信頼性確保　など

なぜ今すぐに導入が進まないのですか？

最大の要因は既存の医療ITシステム（電子カルテなど）の置き換えが困難であることです。また、法規制（例：HIPAA）との整合性、初期導入コスト、業界全体の協調不足なども障壁となっています。

日本の医療機関ではすでに導入されているのですか？

日本国内では一部の先進的な病院や研究機関が実証実験を行っている段階です。大規模な導入はこれからの検討課題ですが、医薬品トレーサビリティや臨床研究支援での活用が先行しています。

ウェアラブルデバイスとの連携にはどう使われるのですか？

スマートウォッチやフィットネストラッカーなどのウェアラブル機器から取得された健康データを、ブロックチェーンに記録することで、患者の状態をリアルタイムで共有し、医師の診療支援や緊急対応に役立てることができます。

ブロックチェーンは患者のプライバシーを本当に守れるのですか？

はい。データは暗号化され、本人の許可なしにアクセスできません。また、「誰がいつアクセスしたか」という履歴もすべて残るため、従来の中央集権型システムよりも高い安全性が期待できます。

スマートコントラクトって何ですか？どう医療に関係するのですか？

スマートコントラクトとは、「あらかじめ設定された条件に基づいて自動的に契約を実行する仕組み」です。医療では、保険請求や薬の処方、予約システムなどを自動化することができ、手続きの効率化につながります。

まとめ

ブロックチェーンは、単なる仮想通貨の基盤技術ではなく、医療・ヘルスケアの世界でも着実に存在感を高めています。患者情報の安全な管理、病院間のスムーズなデータ共有、保険請求の自動化、さらには医薬品の流通トレーサビリティまでその活用範囲は想像以上に広がっています。

とくに「患者中心の医療」が求められる今、ブロックチェーンの「改ざんされない」「透明性が高い」「誰がいつアクセスしたかがわかる」といった特性は、非常に心強い武器になります。とはいえ、課題も少なくありません。既存のITインフラをどう置き換えるか、法律や規制にどう対応するか、導入コストに見合う価値が出せるのか、これらは多くの医療機関が頭を悩ませているポイントです。今後、技術の成熟とともに制度や環境が整えば、私たちの身近な医療にも自然に取り入れられていくはずです。未来の医療が、もっと安全で、もっと効率的で、もっと信頼できるものになる。その鍵を握るのが、ブロックチェーンなのかもしれません。

SotaTek Japanは、ヘルスケア分野において豊富なプロジェクト実績を持ち、ベトナムでもトップクラスのブロックチェーン開発企業として高く評価されています。ヘルスケア業界におけるDXやブロックチェーン活用にご関心のある方は、ぜひお気軽にご相談ください。

詳細はこちら：https://www.sotatek.com/jp/blogs/blockchain-in-healthcare/

お問い合わせ：https://www.sotatek.com/jp/contact/

SotaTek 10年の歩みとマイルストーン

株式会社SOTATEK JAPAN — Mon, 07 Jul 2025 03:20:10 +0000

SotaTekは創業から10年を迎え、多くの挑戦と成長を重ねてまいりました。この10年間の歩みの中で築いてきた主要な出来事や節目を振り返りながら、SotaTekがどのように発展してきたのかをご紹介します。

１０周年のマイルストーンを振り返り

2015年：SotaTek Viet Nam Technology Joint Stock Company設立

SotaTekは2015年、7名のメンバーと共にベトナム・ハノイにて設立されました。ブロックチェーン技術の研究開発を中核に、システムインテグレーション（受託開発）事業も並行してスタート。SotaTekという社名は、「State Of The Art（最先端）」の頭文字である SOTA と、「Technology（技術）」を意味する Tek を組み合わせた造語です。「最先端の技術で、未来を描く」という信念のもと、グローバル市場を見据えた挑戦が始まりました。

2016：日本での受託開発とグローバル展開基盤構築

この年、SotaTekは日本市場への本格的な進出を果たしました。技術力の強化にも注力し、Amazon Web Services（AWS）を活用したライブストリーミングソリューションを開発・リリース。グローバル展開を見据えた技術的・事業的基盤を着実に築き始めた1年となりました。

2017年 - 2018年：仮想通貨取引所リリースとグローバル成長

2017年は、仮想通貨取引所「VCC Exchange」のベトナム国内リリースを皮切りに、欧米や韓国、東南アジアへ受託開発事業を拡大しました。収益は前年比で300％以上の成長を遂げました。さらに、人工知能（AI）の研究開発に特化した新会社を設立し、先端技術への取り組みも加速しました。2018年には、14カ国以上の中小企業・多国籍企業に対してソリューション提供を行い、国際的なプレゼンスを高めました。

2019：SotaTek Japan設立　

翌2019年には、SotaTek Japan（東京都中央区）を設立しました。新区技術の研究開発研究と人材育成を目的とした「SOTA LABS」も新設しました。

2020年 - 2021年：政府プロジェクト参画とSota Holdingス体制への進化

2020年、SotaTekはベトナム政府の主要ITプロジェクトに携わる信頼あるパートナーとしての地位を確立しました。2021年には、親会社Sota Holdingsのもとテクノロジーエコシステムを構築し、イノベーション推進を強化しました。ハノイに3つの新オフィスを開設し、グローバル拠点は7か所に拡大しました。ヘルスケアアプリ開発やブロックチェーン分野で、Techreviewer、Clutch Leader、VINASAなどから高い評価を受け、「Sao Khue賞」を受賞しました。

2022年：SotaTek Korea設立

2022年には、SotaTek Korea設立、大手企業との共同ブランディングパートナーシップにも成功しました。・事業拡大に加え、当社は多くの賞を受賞し、ベトナムのトップB2B企業やICTトップ10に選ばれ、ブロックチェーンサービスプロバイダー賞やSao Khue賞の5つ星認定を獲得しました。 SotaTekの共同創設者兼CTOであるAndy Nguyen氏は、AIやブロックチェーンなど多様な分野から100を超える候補者の中から2022年「若手技術リーダートップ10」に選ばれ、SotaTekの技術力とリーダーシップが高く評価されました。

2023年 - 2024年：SotaTek Australia設立、東京オフィス移転

2023年にはSotaTek Australiaを設立しました。Ava Labsとの提携により、奨学金提供や無料研修を実施し、Web2・Web3革新を支援しました。また、STQBゴールド認証を取得し、ClutchではSalesforce開発会社としてベトナムトップに選ばれました。2024年には、東京銀座オフィス（最寄駅：東銀座）に移転し、デジタルトランスフォーメーション推進体制をさらに強化しました。

2025：創立10周年記念

そして2025年、私たちは10周年という節目を迎えます。この10年で培った経験と信頼、そしてグローバルに広がる仲間と共に、SotaTekは次の10年へと踏み出します。

今後のSotaTek：次の10年へ向けて

10周年を迎えたSotaTekは、これまでの経験と信頼を礎に、さらなる高みを目指して次の10年へと歩みを進めます。テクノロジーの進化が加速する中、私たちはAI、ブロックチェーン、Web3、IoT、クリーンテックといった次世代技術を融合させ、持続可能で人に優しい社会の実現に貢献していきます。今後は、医療、教育、農業、公共インフラなど、社会課題の解決に直結するプロジェクトに積極的に取り組むと同時に、アジアを中心とした海外拠点の拡充、日本市場での人財の強化にも力を入れてまいります。また、グローバルな人財ネットワークの構築と、より包括的なダイバーシティ＆インクルージョン文化の定着を通じて、社員一人ひとりが価値を創造し続けられる組織を目指します。SotaTekはこれからも「最先端の技術で、未来を描く」というビジョンを胸に、技術の力で持続可能な未来を切り拓いてまいります。

詳細はこちら：https://www.sotatek.com/jp/

DEV Community: 株式会社SOTATEK JAPAN

PHP2Shell: Why Updating Your Application Isn't Enough

What is PHP2Shell?

The difference between application and runtime vulnerabilities

Why runtime vulnerabilities are easy to overlook

Which PHP versions received security fixes?

Checking PHP versions in production

Containers don't eliminate runtime vulnerabilities

Prioritizing remediation

Step 1: Identify affected assets

Step 2: Prioritize exposed services

Step 3: Apply vendor-approved fixes

Step 4: Investigate potential compromise

Step 5: Verify and document

Can a WAF protect against PHP2Shell?

Building a better runtime security process

Further reading

Final thoughts

Choosing an AI Development Partner in Vietnam: What Engineering Teams Should Evaluate

1. AI development is more than model integration

2. Evaluate the team's experience with production RAG

Document processing

Retrieval quality

Access control

Evaluation

3. AI agents introduce additional engineering challenges

4. Look for experience beyond AI models

5. Vietnam's AI development ecosystem

6. Questions to ask before starting a project

Final thoughts

Japan's AI Market Is Growing Fast. Why Is Enterprise AI Still Hard to Scale?

1. AI Adoption and AI Production Are Different Problems

2. Legacy Systems Create Integration Challenges

3. RAG Helps, but It Doesn't Solve Everything

Data quality

Access control

Evaluation

Maintenance

4. AI Agents Add Another Layer of Complexity

5. Enterprise AI Needs an Evaluation Strategy

6. Human-in-the-Loop Is an Architectural Decision

7. Start With a Workflow, Not a Model

Final Thoughts

How I’d Build an AI-Powered Workday: From Research to Meetings and Automation

1. Research: Use AI to reduce the time to first insight

2. Writing: Don't ask AI only to "write"

3. Meetings: Turn conversations into structured information

4. Translation: AI as a communication layer

5. Content Creation: Move from blank canvas to editable draft

6. Automation: Move beyond individual AI tools

Start with the bottleneck, not the tool

How to Assess a Legacy System Before Modernization: 7 Technical Checkpoints

1. Maintenance effort is increasing

2. Knowledge is concentrated in a few people

3. Components have reached EOL

4. Integration has become difficult

5. MTTR is getting longer

6. Small changes require large amounts of work

7. Security is becoming harder to maintain

Don't jump directly to a full rewrite

Keep and maintain

Partial modernization

API-based integration

Cloud migration

Full replacement

A risk-based approach works better

Final thoughts

How to Introduce Generative AI into Legacy Systems Without Replacing Everything

The challenge of connecting AI to legacy systems

1. API Integration

2. RAG for Internal Knowledge

3. AI Agents for Cross-System Automation

4. Using AI for Legacy System Maintenance

AI Adoption and Modernization Can Happen in Parallel

What Should Be Evaluated Before Implementation?

Final Thoughts

8 Programming Languages for AI Development in 2026: How to Choose the Right One

Python — Best for General AI Development

R — Statistical AI and Data Analysis

Java — Enterprise AI

ヘルスケアにおけるブロックチェーンとは

ヘルスケアにおけるブロックチェーンの必要性

ヘルスケア分野でのブロックチェーン導入の課題

2019：SotaTek Japan設立　

2023年 - 2024年：SotaTek Australia設立、東京オフィス移転